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Challenges  in  a  Changing  Defense 

Environment 
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Fundamental  Changes 

Three  Major  Challenges 

Adapting  to  Change,  Meeting  the  Challenges 
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Information  Revolution 

Revolution  in  Military  Affairs 

Dynamic  Post-Cold  War  Strategic  Environment 

How  do  we  adapt? 

How  do  we  stay  ahead  of  the  competition? 


Three  Major  Challenges 


How  do  we  adapt  to  concurrently  changing 
strategic  environments,  adversaries,  missions, 
concepts,  doctrine,  organizations,  systems, 
technologies? 

How  do  we  create  products  for  the  warfighter 
which  are  not  obsolescent  when  fielded? 

How  do  we  balance  the  need  for  immediate, 
tailored,  locally  optimized  solutions... 

against  the  desire  for  robust,  enduring,  globally 
capable  solutions 
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Approach 

■  Experimentation  (near  term) 

■  Purpose:  Push  the  edge  of  the  envelope  to  expand  our 
knowledge  and  understanding  of  emerging 
technologies,  systems,  and  concepts 

■  Encourage  &  reward  exploration,  innovation,  risk  taking 

■  Expect,  accept  &  learn  from  concept  “failures” 

■  Determine  key  parameters  &  measures 

■  Improve  our  qualitative  &  quantitative  understanding 

■ 

■  Research  (long  term) 

■  Encourage  research  in  adaptive  systems:  evolutionary 
programming,  genetic  algorithms,  neural  nets 


DJFifCTOfLarf  Of  CdmfioilD  a  OOJ  J7JH  01 


Approach:  Simulation  Based  Acquisition 

■  Revamp  acquisition  process  to  capitalize  on  the 
advances,  advantages  &  potential  of  digital 
information  technology 

■ 

■  Use  shared  access  to  distributed  information  to: 

■  Facilitate  iterative,  spiral  development 

■  Facilitate  collaborative,  concurrent  processes 

■  Create  synergy  between  requirements  pull  &  technology 
push 


Traditional  Defense  Acquisition  Process 

(Paper  Based  Process) 


Top  Level  System 
Requirements 
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SBA  Operational  Concept  Illustration 

(Digital  Information  Based  Process) 
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Extensive  Re-use  Across  Phases  and  Across  Acquisition  Programs 


SBA:  Enabling  Integrated  &  Iterative 

Processes 
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OPERATE  &  SUSTAIN 


TRAIN 


TEST 


CONOPS  DEVELOPMENT 


.OGISTICS  SIMULATIONS 
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SBA:  MULTIPLE  ITERATIONS  (MULTIPLE  DESIGN  LEARNING  CYCLES) 
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Approach 

■  Develop  &  adhere  to  recognized  architectures  & 
standards 

■  Examples:  JTA,  Dll-COE,  HLA,  JMASS,  Database 
standards,  etc 

■  Incentivize  compliance 

■  Engage  professional  societies  (eg,  IEEE,  AIAA)  to 
encourage  broad  recognition  &  acceptance  of 
architecture  &  standards 

■  Plan  for  growth:  Service  to  Joint  to  Coalition, 
Government  +  NGO,  Mil  Spec  to  Commercial 


Summary 

□  Highly  dynamic  defense  environment,  now 
and  for  the  foreseeable  future 

□  Three  major  challenges  will  not  be  easily 
solved 

a  Suggested  approaches  should  help,  but  more 
will  be  needed 

■  Your  ideas  and  support  are  solicited 


BATTLEFIELD  AWARENESS 
UNDERSTANDING  THE  FULL  REQUIREMENT 


Paul  Menoher 
Lt  Gen ,  US  Army  (Ret) 
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“Information  is  the  currency  of 
victory  on  the  modern  battlefield  ” 

Gen  Gordon  Sullivan,  Then  CSA 


The  requirement  is  to  get  the  right  information  to  the  right  people 
at  the  right  time  and  to  present  it  in  a  manner  that  its  significance 
and  implications  for  your  forces  and  missions  are  immediately 
apparent  and  understood. 
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U.S.  Army  Requirements  Process 


■  The  U.S.  Army  has  a  Concept-Based  Requirements  System 
(CBRS)  in  which  the  intellectual  process  of  developing  an 
underpinning  operational  concept  precedes  the  physical 
process  of  developing  new  systems.  This  intellectual  process 
ensures  you  understand  what  you  need  and  how  it  fits  within 
your  overall  operational  or  warfighting  schema.  It  addresses  the 
following  key  factors: 


D  -  Doctrine 
-  Training 

L  -  Leader  Development 
O  -  Organizational  Implications 
M  -  Materiel 
S  -  Soldiers 
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The  Path  to  AAN  Begins  with  the  Advanced  Warfighting  Experiments 

and  Passes  through  Army  XXI 


The  Army  has 
conducted  free  play, 
force-on-force  exercises 
to  give  analytical  validity 
to  vision  and  concepts 


_  m  War  Game 
Series  J 


•  New  Systems 

•  Information  Dominance 

•  Global  Maneuver 

•  Strategic  Focus 

•  Dominates  Competition 


Must  V 
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People 


Leader 

Development 


Training 


•  Legacy  Systems  J 

•  Improved  Situational  m 

Awareness  M 

•  Strategic  Mobility  ^ 

•  Operational-Strategic  Focus 

•  Maintains  Overmatch 


'  Trained  ' 
and  Ready 


Modern 

Equipment 


Doctrine 


y  x  \  x  Regional  Competitors 
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Major  Competitors 
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Goal  of  Force  XXI 


m  To  enable  the  US  Army  to  advance  into  the  21st  Century 
as  a  land  combat  force  that  is  more  lethal  and  survivable 
and  can  control  the  operations  tempo  in  any  future  conflict 
through  enhanced  Battle  Command  and  information 
dominance.  It  is  capable  of: 

-  Simultaneous  planning  and  execution  of  multiple  operations; 

-  Always  maintaining  the  initiative;  and 

-  Forcing  the  enemy  to  operate  from  significant  disadvantage 
or  quit 
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Mental  Agility 


“The  ability  to  leverage  information  dominance 
and  enhanced  Battle  Command  to  act  and  react 
significantly  faster  than  your  opponent  based  on  a 
clear  and  current  understanding  of  the  battlespace 
and  the  enemy  -  to  keep  the  enemy  always  at  risk 
and  preclude  him  from  responding  effectively.  ” 

Menoher,  ‘98 
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VISUALIZATION 


Information  Dominance 

■  The  aggregate  of  Information 
Operations  activities  that  create  an 

advantage 

■  Not  just  in  the  amount  of  information 
but  in  the  relative  capacity  for 

Battlefield  Visualization 

■  The  Commander’s  understanding  of 
his  current  state  in  relation  to  the 
enemy  and  the  environment... 
and... his  ability  to  see  these  in  the 
context  of  a  desired  end  state. . . 
and... his  ability  to  visualize  the 
sequence  of  activity  that  will  move 
his  force  from  its  current  state  to  its 
desired  end  state 
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Battle  Command 


The  art  of  decision-making,  leading  and  motivating 
soldiers  and  their  organization  into  action  to  accomplish 
missions.  It  includes  visualizing  the  current  state  and 
desired  future  state,  then  formulating  the  concept  of 
operation  to  get  from  one  to  the  other  at  least  cost. 

(FM  100-5,  Jun  93,  and  TRADOC  PAM  525-5,  Aug  94) 
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Changing  Nature  of  Battle  Command 


BEFORE 


DIGITIZED 


■  Vertical 

■  Hierarchical 

■  Sequential 


■  Integrated 

■  Collaborative 

■  Concurrent/NRT 


CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD 


CD  CD 


Battlefield  Visualization 


■  “The  process  whereby  the  commander  develops  a  clear 
understanding  of  his  current  state  with  relationship  to  the 
enemy  and  the  environment,  envisions  a  desired  end 
state,  and  then  subsequently  visualizes  the  sequence  of 
events  that  will  move  his  force  from  the  current  state  to  the 
desired  end  state.” 

(TRADOC  PAM  525-70,  Oct  95) 
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One  system  to  train  for ,  plan,  wargame, 
rehearse,  and  execute  operations 
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Battlefield  Visualizatioi 


Today 


Drive  Live,  Virtual  and  Constructive  environments  into  one 
coherent  architecture  for  America’s  Army,  using  the  Army 
Technical  Architecture  as  our  guide 
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Major  Issues 


•  Requirement  for  high  resolution  DTED 

■  Interoperability  and  integration  of  non-,  partially,  and 
differently  digitized  units 

■  Leader  development 

■  Perishable  skills 

■  Requirement  for  synthetic  training  environments  to 
develop,  then  maintain,  requisite  skill  levels  for  leaders 
and  operators 
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Battlefield  Visualization 

Enabling  Technologies 


Visualization 

Databases 


Displays 


Automatic 

Target 

Recognition 


Terrain  ■ 

■  -  Elevation  DB 

-  Features  DB"' 

-  Texture  DB 

-  Images  DB 


Synthetic 

Environments 


Computer 

Hardware 


Dynamic 

-Entities 

-  Units  A 

-  Terrain,' 

-  Environment 


Software 


Al  Collection  Management 
WAN  Info  Retrieval  &  Processing 
Knowledge  Tools 


Networks 
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Technology  Maturation 
Support  to  Battlefield  Visualization 


Today  2000 
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DIED  Level  1  (100  meter) 


Digital  Terrain  Data 


Two  Problems:  Resolution  &  Coverage 


I  I 

•  Coverage  66%  <3% 
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•  Planning-level  data  (world-wide) 

Levels  1  (100m)  and  2  (30m) 


•  Operation-specific  areas  require 
higher  resolution  data 

Levels  3  (10m),  4  (3m),  and  5  (1m) 

•  Virtually  Nonexistent 


cm  E3  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  CD  I - ) 


FUNCTION 

DTED1 

DTED2 

DTED3 

DTED4 

DTED5 

•  Planning 

•  IPB 

•  Msn  Rehearsal 

-  J/G-Staff 

-  S-Staff 

-  Air  (Nap  of  the  Earth) 

-  Vehicle  (2m  obstacle) 

-  Soldier  (1m  survivability) 

•  Targeting 

— 

— 

— MB— 

— 

The  lower  the  echelon .  the  higher  the  required  resolution 
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Interoperability  Issues 


•  Defense  budgets  and  time  will  not  permit  fielding  of 
digitized  Battle  Command  and  intelligence  systems  with 
the  same  level  of  technology  to  the  entire  force 

■  There  will  never  be  a  steady  state;  change  and  evolution 
will  be  constant 

■  There  will  always  be  legacy  systems 

■  There  will  always  be  units  with  the  latest  technology  the 
Army  can  field  (“Haves”)  and  units  with  varying  degrees  of 
less  capable  systems,  if  anything  (“Have  Nots”) 
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Challenge 


■  To  find  an  affordable  way  to  provide  “Have  Nots”  with  the 

minimum  essential,  interoperable,  digitized  Battle 

Command  and  intelligence  systems  to  enable  them  to 

learn  how  to  operate  and  leverage  information  age 

technology  to  achieve  information  dominance  and  mental 
agility 
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Leader  Development  Challenge 


■  Leaders  must  understand  what  digitized  systems  can  and 
cannot  do  and  learn  to  trust  them  and  the  information  they 
provide 

■  They  must  also  learn  how  to  exploit  enhanced  situational 
awareness  to  recognize  battlefield  conditions  and 
dynamically  synchronize  their  combat  power  to  exploit 
opportunities 

■  They  must  maintain  focus  through  their  commander’s 
intent  and  CCIR 
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Meeting  the  Challenge 

Understanding  Decision  Implications  in  the  Information  Age 


Organizations 


Training  and  Doctrine 


Operations 


■  Integration  vice  hierarchy 

■  Focus  on  functions  vice  organizational 
construct 

■  Teams  vs.  functional  staffs 

■  Pervasive  connectivity  -  vertical  and 
horizontal 

■  Chaotic  vice  linear  processes  , 


Dynamic  change  in  decision  processes 
-  mission  rehearsal 

Full  access  to  data 

Training  support  to  a  broader 
perspective 

Dynamic  collaborative  decision  making 
Profound  change  (e.g.  IPB  and  TTP) 


Network 


Networks 


Operational  and 
t  Intelligent  )  4 
Environment 


Speed  enabled  by  knowledge 

Broadened  perspectives  on  information 
operations 

Multidimensional  operations 
Profound  NRT  knowledge  based 
New  set  of  force  protection  challenges 
Focused  analysis  at  point  of  decision 


Quality  vs.  quantity 

Accuracy  and  validation  of  knowledge 

Virtual  headquarters  seen  as  “real” 
entities 

“Machine-aided”  decision . .  .human 
confidence 
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Perishable  Skills 


■  Digital  skills  of  leaders  and  operators  are  extremely 
perishable 

■  A  “one  time”  pass  through  a  training  institution  and/or  a 
“Have”  unit  is  not  enough  to  maintain  these  skills 

■  We  must  develop  high  fidelity,  synthetic  training 
environments  to  support  individual  and  collective  training 
of  these  skills  in  garrison 
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Actions  Being  Taken 
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ng  Environment 


Combat 

Synthetic  Training  Assessment 
Range  (CSTAR)  -  Phase  I 

■  Merges  live  play  and  constructive 
simulation  into  coherent  300  x  300  km 
virtual  scenario 

-  Employs  realistic  collection  models 

-  Supplements  or  supplants  scarce 
sensors 

■  Enables  battle  command  training 

-  Responsive  to  commander 
directions 

-  Fuels  fires  and  maneuver 
integration 

■  Supports  new  equipment  fielding 

-  CGS,  TCS,  ASAS-RWS 
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NTC  -  Ft  Hood  (Phase  1 ) 


ASAS-RWS 


R-Bde 


TROJAN 


Parent  Division 


NATIONAL 


"•X*'  jstars 


GUARDRAIL 


NTC 


PREDATOR 


Ft.  Hood 
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Digital  Terrain  Elevation  Data 


!  J ROC- Approved;  PBD  Approved;  Shuttle  Flies  in  ‘00,  Data  in  ‘01 
!  DTED  Is  a  Significant  Shortfall-Not  Currently  Available 

In  the  Resolution  or  Timelines  Required  by  the  Warfighter 
!  DTED  Level  2  Data  (30M  Post  Spacings)  Will  Provide  a  Robust 

Standardized  Database  for  Mission  Planning  and  Crisis  Response 
!  An  Enabling  Technology  for  Battlefield  Visualization 


DTED  Level  4,  5  (3m  and  1m  Post  Spacings)  Required  for  Operations 
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Rapid  Terrain  Visualization 
ACTD  Components 


Rapid  T.V.  ACTD 
JPSD 


Rapid  Terrain 
Visualization 
(RTVIZ)  ATD 

JPSD 


Commander  Monitors  the  Battle 

Movement  to  Contact  “On  Track” 


TERRAIN 

COMPONENT 


Battlespace  Command 
and  Control  (BC2)  ATD 

CECOM 


C2  /  VISUALIZATION 
TECHNOLOGIES 
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Blue  Data 
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Technology 


Goal:  To  rapidly  collect  and  generate  high  resolution  terrain  data  in  time  to 
support  force  projection  operations  and  to  integrate  current  situational  data 
and  mission  planning  and  rehearsal  capabilities. 
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Value  Added 


Merge  ATCCS  inputs  in  a  single  platform,  output  to  large  screen 
displays  where  appropriate  or  individual  private  displays  for 
commanders  on  the  move! 

Move  battlestaffs  (S/G/J)  into  the  21st  century... “yellow  stickie” 
wargaming  on  paper  maps  replaced  by  competitive  force 
engagement  in  3D  on  high  resolution,  virtual  replication  of  the 
battlespace... artificial  intelligence  aided  analysis... objectivity 
replaces  subjectivity 

Enable  every  commander  to  see  his  battlespace,  the  array  of 
friendly  and  enemy  forces  on  it,  and  to  plan,  wargame  and 
rehearse  before  ever  making  contact  with  the  enemy 

Reduced  uncertainty-replace  subjectivity  with  objectivity, 
across  all  BOS 
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Battlefield  Visualization 

Our  Objective 


Drive  Live,  Virtual  and  Constructive  environments  into  one 
coherent  architecture  for  America’s  Army,  using  the  Army 
Technical  Architecture  as  our  guide 


One  system  to  train  for,  plan,  wargame, 
rehearse,  and  execute  operations 
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Conclusion 


■  Digitization  and  enhanced  Battlefield  Awareness  stand  to  bring 
about  many  advances  in  Battle  Command  and  overall 
warfighting  capabilities 

■  However,  integrating  and  optimizing  digitization  and  fully 
leveraging  battle  awareness  are  complex  tasks  encompassing 
many  more  challenges  than  simply  acquiring  new  systems 

■  There  is  much  more  involved  in  articulating  requirements  than 
merely  writing  system  specifications  or  introducing  new 
technologies 

■  Thinking  through  the  DTLOMS  provides  a  good  start  to 
understanding  the  full  requirement 
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Commander  Monitors  the  Battle 


Movement  to  Contact  “On  T rack” 
Situational  Awareness— Red,  Blue,  Terrain,  Weather 


BPV  arguably 

the  largest 
Crowd  Pleaser 
at  Army 
Enterprise, 

AE  III 
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Naval  Aviation  Systems  Team 


Requirements  Generation 


NAVAL  AIR  WARFARE  CENTER 


WEAPONS  DIVISiON 


•  Know  the  environment. 

•  Know  your  adversary. 

•  Know  your  strengths. 

•  Know  your  weaknesses. 

•  Your  strengths  and  weaknesses,  arrayed  against  your 
adversary’s  strengths  and  weaknesses,  should  reveal  your 
requirements. 

“Know  the  enemy  and  know  yourself;  in  a  hundred  battles  you  will  never  peril  When  you  are 
ignorant  of  the  enemy  but  know  yourself,  your  chances  of  winning  or  losing  are  equal  If  ignorant 
both  of  your  enemy  and  of  yourself,  you  are  certain  in  every  battle  to  be  in  peril  ” 

Sun  Tzu,  The  Art  of  War,  Sixth  Century  B.C. 


Today’s  Environment 
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RF  Link 
Future  RF  Link 
Footpath 
Network 
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iSSi  Emerging  Operational  Concepts 


WEAPONS  DIVISION 


Dominant  Maneuver 
Precision  Engagement 


Massed 


Coalition  Partners 


Joint  Forces 


Focused  Logistics 
Full-Dimensional  Protection 


Effects 


Operational  Warfare  Drivers 


WEAPONS  DIVISION 


Aircraft 

Weapons 


Single  seat,  multi-mission,  smart/ 
programmable 

Guided,  standoff,  autonomous 


Force  Fewer  platforms,  people,  weapons 

Structure 


Threat 


Lethal,  mobile,  electronically  agile 


Operational  Enable  rapid,  decisive,  low  loss  victory 

Concepts 


Improved  planning  methods  and  tools  required  to  meet 
high  information  demands  of  modern  strike  warfare 


m-  >  90%mobile,  main  threat  to  JSF  (RADM  Steidle) 

»-  High  interest  “time  critical”  targets 


»*"  Relatively  few,  but  can  drain  JTF  resources  (1994  DSB) 


kf  Battlefield  changes  dramatically  within  traditional 
planning  &  execution  timelines 

Mission  planning  is  the  pacing  function  in  joint  precision 
_ interdiction  timeliness  (1994  DSB) 


Network  Centric  Warfare 
Brave  New  World 
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Network  Centric  Warfare 
Increases  Joint  Combat  Power 


WEAPONS  DIVISION 


Results  for  Precision  Engagement 

*  Operational  Impact 

-  Dramatic  Early  Results 

-  Greatest  Rates  of  Change  in  Initial  Phase  of  a  Campaign 

-  Inflicts  Maximum  Losses  on  the  Enemy 

-  Shortens  Timelines 

-  Locks  out  Enemy  Options 


Time 


Network  Centric  Warfare  t 
'ISSa  Integrated  Planning  &  Execution  0 
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Time-critical-target/mobile 
SAM  targeting  data  linked  to 
Afloat  AOC 


National  sensor  updates  mission 
planning  threat  data  base\cues 
JSTARS  via  TRAP 


UAV  passes  time-critical- 
target  location  to  JSTARS 


■  <*> 


Mobile  SAM  engaged 
using  JSTARS 
targeting 
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JFACC  Afloat  real-time  tactical  picture 
enables  sensor-to-shooter  retasking  & 
situational  awareness  updates 


Mission  plan  update,  JSOW 
targeting  data,  threat  avoidance 
routing  relayed  to  TACAIR 


Time-critical-targets/advanced  mobile  threats  demand 
integration  of  theater  sensor  data  into  real-time  battle 
management  and  mission  plan  updates 


Scope  of  Land  Attack  Targeting  2010 
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Strike  Timeline 


NAVAL  AIR  WARFARE  CENTER 
WEAPONS  DIVISION 


CURRENT  STRIKE  TIMELINE 
ATO 

Day  1 _ A _ 


0600 

Day  2. 
0600 

Day  3. 
0600 


Plan 

ATO 

_ B _ 

Gen  Plan 

ATO 

_ C _ 

Strike  Gen  Plan 


Day  4  T _ 

0600  Assess  IStrike  Gen 


Re-strike# 
Day  5  Required* 

0600  Assess 


Day  6 
0600 


Re-Strike 


_ Today's 

IStrike  Timeline 
L  12-24  hrs 


Assess 


NEED:  COMPRESS  “THE  TIMELINE” 


|-  DETECT  | - DECIDE - 1- 

ti _ 1*2 _ L 

Tgt  Detection  Receipt  of  Target  Data 
IPOB 

\Targeteering 

\Planning 

\Weaponeering 
n.  Asset  Allocation 

\Transfer  of  Data 


Fire  Decision 


DELIVER 


— j—  Kil 


Toda' 


Shooter  rec  Impact 
Tgt  data 

Ingress 

Missile 

Launch 


•  •  •  • 


Tomorrow 


Timeline  Reduction 
Required 

Biggest  payoff  is 
Reducing  t2  to  t3 


Cooperative  Engagement  Capability 
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SENSOR  BENEFITS 

•  NEAR  REAL  TIME  EXCHANGE 

OF  SENSOR  MEASUREMENT  DATA 

•  CUEING  OF  REMOTE  SENSORS 

•  JAM  RESISTANCE/LOW  / 

PROBABILITY  OF  INTERCEPT  / 


The  Future:  Seemless  Integration 
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Panel  IV 


DIRECTORATE  OF  COMMAND  &  CONTROL  I 


■  Task:  Build  an  analytical  bridge  between  the 
warfighter  and  the  engineer 

■ 

■  Byproduct:  Create  synergy  (vice  tension) 
between  “requirements  pull”  and  “tech  push” 

■ 

■  Framework:  Simulation  Based  Acquisition 

■  Examples  of ‘bridges’: 

■  JSF 

■  USAF  C2 

■  Some  bridge  building  tools: 

■  AFRL  Virtual  Testbed 
■ JMASS 


SBA  Operational  Concept  Illustration 

(Digital  Information  Based  Process) 
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ADVANCED  PLATFORM 


ADVANCED  COMBAT  SYSTEMS 
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Eng  Development 
&  Manufacturing 


Extensive  Re-use  Across  Phases  and  Across  Acquisition  Programs 


Simulation  Based  Acquisition 
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■  Revamp  acquisition  process  to  capitalize  on  the 
advances,  advantages  &  potential  of  digital 
information  technology 

■ 

■  Use  shared  access  to  distributed  information  to: 

■  Closely  link  stakeholders  in  product  development 

■  Facilitate  iterative,  spiral  development 

■  Facilitate  collaborative,  concurrent  processes,  IPPD 

■  Create  synergy  between  requirements  pull  &  technology 
push 


Anticipated  SBA  Impact  on 
Analytical  Link 
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■  Better,  more  consistent  models 

■  More  support  for  development  of  M&S  tools 

■  Better  access  to  data,  authoritative  information 

■  Better  synthetic  environments 

■  Earlier  access  to  product  information 

■  Better  understanding  &  definition  of  requirements 

■  Better  linkage  of  requirements  to  performance 

■  Better  understanding  of  thresholds 

■  Easier  to  identify  &  focus  on  prime  OT&E  areas 


■  Joint  Strike  Fighter 

■ 

■  USAF  Command  &  Control 


SBA  Analytical  Linkage  Example: 
JOINT  STRIKE  FIGHTER 
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•  Delay  locking  in  requirements 

•  JSF  has  used  Interim  requirements’;  no  ORD  until  ‘00 

•  Evolve  requirements  with  an  integrated  set  of 
simulations 

•  Campaign/mission  modeling  with  constructive  simulations  (95-96) 

•  Virtual  simulations  (w/man-in-the-loop) 

•  Interactive  digital  simulations  to  evaluate  specific  functional 
requirements  (97-99) 

•  Virtual  Strike  Warfare  Environment  exercises  (98) 

•  Provide  early  weapon  system  experience  for 
warfighters  for  conceptual  development 


•  Use  SBA  analytical  construct  for  cost  &  operational 
performance  trades,  within  warfighter  CONOPS 


13 


SBA  Analytical  Linkage  Example: 
AF  Command  &  Control 
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•  ESC  SBA  initiative: 

Link  requirements  M&S  tools/data  (used  by  C4ISR  operators) 
with  system  design  &  build  tools/data  (used  by  C4ISR 
developers) 

•  Intent: 

-  Provide  single  continuous,  traceable  flow  of  data  from 
operational  need  to  system  capability 

-  Integrate/map  CINC  C2  requirements  with  Service 
baseline  system  capability 

-  Merges  Joint  C4ISR  Architecture  &  Planning  System 
(JCAPS)  and  proven  model-based  system  engineering 
process  (Model  Reference  Technology) 
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SBA  for  C2  at  ESC: 
Model  Reference  Technology 
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SBA  Analytical  Tools:  Examples 
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■  JMASS 


“The  Network  is  the  Simulator” 


SBA  Analysis  Tool:  JMASS 


DIRECTORATE  OF  COMMAND  &  CONTROL  I 


Set  of  tools  and  services  that  allow  user 
to  build,  configure  and  execute 
engineering  and  engagement 

level  simulations 


Now  a  Joint  Program 


The  Essence  of  JMASS 
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Model  Standards 

♦  SEI  Software  Structural  Model  for  Reuse 

♦  Model  Application  Programming  Interface 

Simulation  Support  Environment 

♦  Simulation  Engine 

♦  Communications  Architecture 

♦  Visual  Development  Tools 

♦  Analysis  Tools  j|j 

♦  COTS  &  Legacy  Tool  Interface  — 

Model  Library  &  Repository 

♦  Local  Model  and  Data  Library 

♦  Remote  Model  Repository 

♦  Contains  DIA-validated  threat  models 


CONFIGURE 


EXECUTE 


POS 

PROC 


LIBRARY 

-  Models 

-  Objects 

-  Scenarios 


REUSE 


Yield  is  common,  reusable,  interoperable,  validated  models 


Summary 
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■  Simulation  Based  Acquisition  provides 
framework  to  analytically  link  warfighter  to 
developer,  other  stakeholders 

■  SBA  approach  will  emphasize  and  improve 
analytical  tools,  product  models,  visualization 

■  SBA  will  enhance  access  to  critical  authoritative 
information  needed  for  warfighter  and  developer 
tradeoff  decisions 

■  Programs  are  already  embracing  the  SBA 
construct 


High  Range  Resolution  Profile  Generation  Using 
Sensor  And  Signature  Simulation 
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*  Colsa  Corporation,  Huntsville,  AL 
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Abstract 

Sensor  and  Signature  Simulation  (SASS),  is  a  simulation  which  was  developed  for  the  National 
Missile  Defense  (NMD)  Ground  Based  Radar-Project  Office  (GBR-PO)  to  produce  Radar  Cross 
Section  (RCS)  and  target  signatures.  It  is  utilized  within  the  NMD-GBR  Hardware  in  the  Loop 
(HWIL)  Test-bed,  as  well  as  the  THAAD  Radar  Test-bed.  Target  High  Range  Resolution  (HRR) 
profiles  generated  by  SASS  are  used  to  emulate  and  execute  tactical  radar  operations.  Target  mod¬ 
els  are  built  up  from  simple  component  types,  such  as  flat  plates,  frustums,  spheres/spheroids  and 
fins  whose  known  radar  signature  is  characterized  in  terms  of  scattering  centers.  The  radar  signa¬ 
tures  of  the  complete  target  model  are  determined  by  reducing  the  target  to  a  list  of  effective  scat¬ 
tered.  In  this  paper,  we  will  show  how  to  build  and  execute  targets  using  SASS,  and  how  to 
generate  the  corresponding  HRR  Principle  Polarization  (PP)  and  Orthogonal  Polarization  (OP) 
range  profiles.  Comparisons  with  real  world,  and  other  models  (such  as  Xpatch),  will  be  used  as  a 
means  of  validation.  The  most  important  attribute  of  SASS  is  speed  of  execution.  Additionally,  it 
is  quite  easy  to  build  and  execute  targets  using  SASS.  Wide  Band  (WB),  NB,  and  HRR  -PP  and  - 
OP  profile  examples  will  be  used. 

I.  NMD  GBR  HWIL  itesT-BED  Block  Diagram  [i] 

Figure  1  shows  a  block  diagram  for  the  NMD-GBR  HWIL  Test-bed. 


Scenario  Generator 
Sensor  &  Algorithm  Models 

Data  Reduction  Tools  r  lgUTC  1 

Non-Real-Time 


The  Target  Complex  generator  (TCG)  was  developed  to  digitally  simulate  the  antenna,  Beam 
Steering  Generator  (BSG),  transmitter,  waveforms,  receiver  and  Analog  to  Digital  (A/D),  of  the 
tactical  radar  in  all  three  monopulse  channels.  The  TCG  provides  the  required  signals  to  the  Data 
Processing  Equipment  (DPE),  via  a  Fiber  optic  Digital  Data  Interface  (FDDI),  and  to  the  Signal 
Processing  Equipment  (SPE),  via  a  High  Performance  Parallel  Interface  (HiPPI). 

II.  Sensor  and  Signature  Simulation  (SASS)  [2-5] 

SASS  contains  models  of  the  GBR  radar  signal  and  data  processors  to  provide  for  an  all  digital 
simulation  of  the  radars.  SASS  provides  high  fidelity  representation  of  modem  high  frequency, 
coherent  chirp  radar.  All  digital  models  within  SASS  are  systematically  constructed  and  executed, 
through  a  user  friendly  set  of  graphical  user  interfaces  (GUIs).  The  GUIs  also  allow  for  extensive 
generation  and  graphical  display  of  targets,  engagement  and  signatures.  This  includes,  three- 
dimensional  (3-D)  static  and  dynamic  target  representation,  target  scattering  static  patterns,  radar 
engagement  (range,  altitude,  aspect  angle,  etc.)  histories,  RCS  and  phase  histories,  stacked  narrow 
band,  medium  band  and  wide  band  compressed  pulse  shapes  and  measurements.  Sensor  error  anal¬ 
ysis  are  also  available.  Figure  2  contains  SASS  external  interface  block  diagram  and  shows  the 
host  and  interfaces  for  the  SASS  application. 


Figure  2 


Target  models  are  built  up  from  simple  component  types,  such  as  flat  plates,  frustums,  spheres/ 
spheroids  and  fins  whose  known  radar  signature  is  characterized  in  terms  of  scattering  centers.  The 
radar  signature  of  the  complete  target  model  can  then  be  determined  by  reducing  the  target  to  a  list 
of  effective  scatterers,  complex  amplitudes  and  their  positions  as  projected  along  the  radar  line  of 
sight.  The  most  important  attribute  of  SASS  is  speed  of  execution.  For  example,  using  a  Silicon 
Graphics  02  machine  SASS  produces  an  output  in  less  than  three  seconds,  even  for  the  most  com¬ 
plex  targets.  Additionally,  it  is  quite  easy  to  build  and  execute  targets  within  SASS 

Scattering  center  characterization  describes  the  processing  necessary  to  determine  where  the 
effective  scattering  centers  of  the  target  are  located  and  in  what  manner  they  contribute  to  the  radar 
signature.  This  capability  involves  the  determination  of  visible  scattering  centers  and  the  corre¬ 
sponding  complex  electromagnetic  scattering  amplitude.  This  characterization  calculates  the  com¬ 
plex  electromagnetic  scattering  amplitude  using  an  extension  of  the  scattering  center 
approximation  developed  by  Crispin  and  Maffet.  In  this  approximation  the  targets  are  first  broken 
up  into  geometrical  sub-elements,  then  Physical  Optics  (PO)  is  used  to  calculate  the  contribution 
from  surface  returns  of  the  sub-elements  and  the  Geometrical  Theory  of  Diffraction  (GTD)  is  used 
to  calculate  the  diffraction  contribution  from  the  joints  and  edges  of  these  sub-elements.  The  PO 
returns  are  calculated  for  surfaces  perpendicular  to  the  line-of-sight,  where  PO  is  a  good  approxi¬ 
mation,  and  GTD  is  not.  For  the  other  cases,  GTD  is  used.  Since  our  radar  has  a  monostatic 
arrangement,  the  GTD  returns  come  only  from  points  on  the  edges  where  the  edge  is  perpendicular 
to  the  line  of  sight.  Thus,  both  the  PO  and  GTD  returns  are  equivalent  to  returns  due  to  effective 
scattering  centers,  located  at  the  surface  edges  for  PO  contributions  and  located  at  the  edges/joints 
nearest  to  the  radar  for  GTD  contributions.  With  SASS,  the  calculations  are  taken  one  step  further, 
the  remaining  unshadowed  scattering  centers  are  then  summed  coherently  (taking  into  account  the 
distances  from  the  radar  of  each  scattering  center  along  the  radar  line-of-sight),  giving  a  total  com¬ 
plex  scattered  return  towards  the  radar.  From  this,  the  target  RCS  is  calculated. 

Figure  3.a  shows  a  typical  generic  target  (Re-entry  Vehicle  (RV))  constructed  using  SASS, 
while  Figure  3.b  shows  the  corresponding  Narrow  Band  (NB)  RCS  (dBsms)  at  X-Band  versus 
aspect  angles  (degrees).  Figure  3.c  Shows  the  corresponding  Wide  Band  (WB)  target  signature  at 
the  same  frequency. 


Figure  3.a 


III.  Stepped  Frequency  Waveforms  and  High  Range  Resolution  Profiles  i«] 


Discrete  Fourier  Transform  (DFT)  processing  of  a  series  of  I  and  Q  samples  collected  on  a  pulse 
by  pulse  basis  can  be  used  to  generate  a  high  resolution  range  profile  of  an  isolated  target.  This  can 
be  accomplished  by  transmitting  a  sequence  or  burst  of  Narrow  Band  (NB)  monotone  pulses  that 
are  stepped  in  frequency.  Such  pulses  are  referred  to  as  Stepped  Frequency  waveforms  (SFWF). 
These  pulses  illuminate  a  target  located  in  the  far  field,  and  after  the  radar  receiver  collects  a  burst 
of  echo  pulses,  the  radar  processor  Fourier  transforms  the  signal  into  a  target  range  profile.  The 
processed  target  range  resolution  is  c/(2NAf)  where  c  is  the  speed  of  light,  N  is  the  number  of 
steps  in  the  burst,  and  Af  is  the  frequency  step  size. 

In  general,  the  Pulse  Repetition  Frequency  (PRF)  for  a  SFWF,  during  the  nth  step,  can  be 
expressed  as 


f„=f0  +  nAf  (EQ1) 

where  /0  is  the  radar  operating  frequency  and  Af  is  the  frequency  step.  Assuming  returns  form  a 
stationary  target  at  range  R ,  then  the  nth  video  quadrature  components  for  a  processed  SFWF  are 


4(0  =  C«cosV„  (EQ2) 

4(0  “  C«sin^«  (EQ3) 


where  t| Tn  =  (-4jt Rfn)/ c,  Cn  is  the  amplitude  for  the  nth  return.  The  complex  video  signal  is 
then  given  by 


*„( 0  =  4(0+74(0  - 


(EQ4) 


It  follows  that  the  sampled  quadrature  components  are  made  of  discrete  samples  the  target 
reflectivity  in  the  frequency  domain.  And  hence,  this  information  can  be  transformed  into  range 
refelcivity  series  by  using  the  Inverse  DFT  (IDFT).  More  precisely,  the  synthesized  range  profiles 
is  given  by. 


N~ 1  r/^/Al  jlnnl 

Hl  =  e  e  N  ;(0<1<N- 1)  (EQ5) 

n  =  0 

The  instantaneous  frequency  of  the  nth  video  signal  can  be  evaluated  as 

.  2  R  x  ?  fn 

fd  =  —fn  +  —R  (EQ6) 

where  the  first  term  of  the  right  hand  side  of  (EQ  6)  corresponds  to  the  frequency  change  associ¬ 
ated  with  changing  the  transmitted  frequency  and  range  to  the  target.  Alternatively,  the  second 
term  is  associated  with  the  targets  induced  Doppler  due  to  its  motion. 


The  unambiguous  range  associated  with  a  SFWF  can  be  found  to  be 


R  = 

u  2A f 

and  the  corresponding  range  resolution  is 


(EQ7) 


A  R 


c 

2NAf 


(EQ  8) 


As  indicated  by  (EQ  8)  the  total  number  of  frequency  steps  and  the  step  size  determine  the  final 
synthesized  range  resolution.  Thus,  one  can  perhaps  conclude  that  by  increasing  the  step  size  then 
range  resolution  can  be  improved.  This  is  true,  however,  in  order  to  avoid  aliasing  one  must  choose 
the  frequency  step  so  that 


where  E  is  the  target  extent  in  meters.  Additionally, 


^ K 


(EQ9) 


(EQ  10) 


where  X  is  the  pulse  width. 


IV.  Utilization  of  SFWF  within  SASS 

We  developed  a  SFWF  processing  module  within  SASS  in  order  to  generate  HRR  profiles  of 
SASS  targets.  For  this  purpose,  each  sub-pulse  within  a  burst  is  Linear  Frequency  Modulated 
(LFM),  where  the  bandwidth  corresponds  to  A  f.  The  choice  of  the  number  of  steps  within  a  burst 
and  the  step  size,  are  dynamically  computed  on  the  basis  of  the  target  extent  and  the  desired  band¬ 
width.  Further  more,  HRR  profiles  for  SASS  targets  are  produced  for  both  Principal  Polarization 
(PP)  and  Orthogonal  Polarization  (OP).  Both  PP  and  OP  signatures  along  with  their  ratio,  are  then 
stored  in  binary  format,  for  later  use  in  the  GBR  HWIL  test-bed. 

The  NMD-GBR-PO  requested  that  all  of  the  HWIL  entities,  including  SASS,  undergo  a  Verifi¬ 
cation,  Validation,  and  Accreditation  (VV&A)  process.  The  guidelines  established  for  the  VV&A 
process  include:  (1)  SASS  output  comparisons  with  real-world  data  produced  from  static  range 
measurements  and  flight  tests;  and  (2)  Touchstone  /  simulation  comparisons.  The  touchstone 
model  chosen  for  SASS  comparisons  is  Xpatch  Comparisons  with,  real  world,  and  other  models 
(such  as  Xpatch)  have  been  used  as  a  means  of  validation.  However,  because  of  the  security  classi¬ 
fication  nature  of  these  analysis,  we  will  not  show  these  results. 

Figure  4.a  shows  a  typical  synthetic  HRR  PP  signature  produced  by  SASS.  In  this  case,  the 
generic  RV  shown  in  Figure  3.a  was  used  for  demonstration.  The  center  frequency  is  1 0 GHz ,  and 
the  bandwidth  is  equal  to  AGHZ.  The  frequency  step  is  A f  =  2>5MHz  .  The  generic  RV  is 
1.75m  long,  with  base  radius  equal  to  0.57m .  The  nose  diameter  is  0.26m .  Figure  4.b  shows 
the  corresponding  OP  signature. 


V.  Conclusions 


A  very  fast  running  simulation,  entitled  Sensor  and  Signature  Simulation  (SASS)  was  devel¬ 
oped,  validated,  verified,  and  utilized  for  use  within  the  NMD  GBR  HWIL  test-bed,  as  a  means  for 
radar  RCS  and  target  signature  generation.  Narrow  band,  wide  band  target  signatures  are  only  two 
of  the  many  outputs  SASS  can  produce.  A  synthetic  High  Range  Resolution  (HRR)  module  was 
also  developed  and  tested.  In  this  case,  each  of  the  SFWF  sub-pulses  is  LFM  modulated  and  pulse 
compressed  in  order  to  synthesize  the  desired  target  signature.  Both  PP  and  OP  signatures  as  well 
as  their  respective  ratio  are  calculated  and  stored  in  binary  format  for  use  with  the  test-bed.  For 
illustration,  a  typical  sub-set  of  SASS  outputs  is  presented  in  this  paper. 
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ABSTRACT 

The  procedures  to  assess  the  toxicological  and  environmental  impact  of  pyrotechnic 
obscurant  munitions  requires  detailed  knowledge  on  the  mass  and  distribution  of  the 
chemical  species  produced,  in  order  to  comply  with  national,  and  international  laws.  This 
paper  will  describe  the  various  techniques  the  UK  are  assembling  to  assess  obscurant 
pyrotechnic  munitions. 

The  chemical  species  generated  in  the  by-products  of  combustion  and  those  found  in  the 
residue  following  ignition,  are  determined  by  controlled  laboratory  tests.  Combustion  of  the 
pyrotechnic  composition  is  performed  within  a  Parr  bomb  chamber,  with  an  air  atmosphere 
pressurised  to  106Pa.  The  resultant  chemical  species  are  analysed  using  a  combination  of 
thermogravimetry  -  FTIR  analysis,  thermal  desorption/gas  chromatography/mass 
spectrometry,  and  aqueous  extraction  techniques.  The  probabilistic  field  trial  concentration 
and  dosages  during  dissemination  of  the  obscurant  screen  are  determined  as  a  function  of 
meteorological  conditions  and  topography  using  the  computer  program  SCIPUFF.  Any 
hazard  to  personnel  can  then  be  assessed  by  comparison  with  exposure  limits  published  by 
the  UK  Health  and  Safety  Executive.  The  description  of  these  analytical  techniques  will  be 
illustrated  by  examples  from  the  recent  assessment  of  the  L84A1  hand  thrown  smoke 
grenade. 

1.  INTRODUCTION 

Historically,  military  smokes  and  pyrotechnics  have  not  been  subject  to  any  statutory 
regulation  relating  to  their  toxicity.  In  view  of  the  recognition  by  the  UK  MoD  of  its  duty  of 
care  in  health,  safety  and  environmental  issues,  future  procurements  of  obscurant  munitions 
will  be  required  to  address  these  issues.  To  this  end,  a  set  of  toxicity  testing  guidelines  were 
drawn  up  in  1988,  and  subsequently  revised  in  1996  [1],  The  revisions  took  into  account 
technological  advances  in  munition  design  and  importantly  gave  consideration  to  the 
context  in  which  the  munition  is  to  be  used,  distinguishing  between  training  or  operational 
use.  The  revised  guidelines  have  been  proposed  to  NATO  and  currently  form  the  basis  of 
future  UK  assessment  methodology. 

This  paper  describes  the  revised  guidelines  and  the  development  work  undertaken  in 
support  of  their  practical  implementation.  This  is  illustrated  by  means  of  an  example,  taken 
from  the  recently  considered  assessment  of  the  L84A1  hand  thrown  smoke  grenade. 


It  must  be  emphasised  that  the  results  from  this  study  relating  to  the  inhalation  hazard  from 
the  L84A1  are  subject  to  ratification  by  the  UK  medical/toxicological  authority. 


2.  TOXICITY  TESTING  GUIDELINES 

According  to  the  revised  guidelines  for  toxicity  testing  of  smokes  and  pyrotechnic  mixtures 
[1],  the  most  significant  toxicology  aspect  relates  to  the  inhalation  of  the  airborne 
components.  It  also  states  that  a  lesser  threat  is  posed  by  cutaneous  and  ocular  routes  of 
exposure.  In  addition,  environmental  issues  need  to  be  considered,  such  as  the  surface 
deposition  of  chemical  species  leading  to  the  poisoning  of  flora  and  fauna  and 
contamination  of  water  sources.  However,  the  scope  of  this  paper  is  limited  to  exposure  via 
inhalation. 

The  assessment  guidelines  can  be  broken  down  into  the  following  discrete  stages: 

Identification  and  quantification  of  airborne  species:  This  can  be  estimated  from 
knowledge  of  the  composition  and  prediction  of  likely  chemical  reactions.  However,  the 
preferred  approach  is  to  identify  and  measure  each  species  within  the  smoke  cloud  directly, 
by  chemical  analysis. 

Determination  of  safe  exposure  limits:  An  exposure  limit  will  be  a  function  of  factors 
such  as  frequency  and  duration  of  exposure  (for  example,  single  exposure  will  have  a 
different  limit  to  multiple  long  term  exposures).  Therefore,  the  proposed  method  of  use  of 
the  obscurant  munition  must  first  be  reviewed  as  this  will  input  into  the  selection  of  an 
appropriate  safety  limit.  To  this  end,  the  toxicity  guidelines  draw  parallels  with  workplace 
exposure  to  chemical  guidelines  and  recommend  that  Government  specified  Occupational 
Exposure  Limits  (OELs)  are  used  as  the  source  of  exposure  limits. 

Determination  of  exposure  to  each  chemical  species:  To  determine  exposure,  the 
atmospheric  dispersion  of  the  obscurant  cloud  under  a  range  of  meteorological  conditions 
needs  to  be  considered.  To  physically  conduct  such  assessments  under  a  range  of 
meteorological  conditions  is  impractical,  therefore  some  form  of  prediction  must  be 
substituted. 

3.  L84A1  HAND  THROWN  SMOKE  GRENADE 

The  L84A1  hand  thrown  smoke  grenade  (figure  1)  is  in  service  with  the  British  Army.  The 
grenade  contains  red  phosphorous  as  the  smoke  producing  composition,  with  a  payload 
mass  of  approximately  225g.  The  grenade  is  of  conventional  design  with  twist  and  pull 
safety  pin  and  fly  off  lever  operating  a  percussion  ignition  train.  Operation  is  by  removal  of 
the  safety  pin  and  throwing  to  the  location  where  the  smoke  is  required.  Subsequent 
initiation  of  the  central  burster  charge  disseminates  the  payload  over  an  area  of 
approximately  5m  radius,  giving  a  typical  screen  duration  of  30  seconds.  The  active 
ingredient,  in  terms  of  screen  effectiveness,  is  phosphoric  acid  (H3PO4),  formed  on  the 
reaction  between  phosphorus  pentoxide  and  moisture  in  the  atmosphere.  Therefore, 
humidity  will  affect  the  performance  of  the  munition,  and  the  safety  distance. 


Figure  1  -  L84A1  hand  thrown  smoke  grenade 

4.  CHEMICAL  COMPOSITION  OF  SMOKE  CLOUD 

The  approach  adopted  in  identifying  and  quantifying  the  chemical  species,  was  by  means  of 
direct  analysis  of  the  resultant  smoke  cloud.  Combustion  of  the  pyrotechnic  composition 
and  containment  of  the  resultant  by-products  was  performed  in  a  Parr  bomb  chamber  [2], 
After  allowing  the  aerosol  to  condense,  the  products  of  reaction  were  collected  by  purging 
through  Tenax  adsorption  tubes  and  analysed  using  a  thermal  desorption  -  gas 
chromatography  -  mass  spectrometry  technique.  The  condensed  aerosols  were  collected  by 
washing  with  water,  and  the  resulting  solutions  were  analysed  using  ion  chromatography 
and  direct  current  plasma  spectrophotometry.  Combustion  was  also  carried  out  using 
thermogravimetry  -  Fourier  transform  infrared  spectroscopy,  to  examine  weight  loss  and  to 
identify  the  major  constituent  of  the  smoke  aerosols. 

In  total,  34  chemical  species  were  identified.  Table  1  contains  a  subset  of  the  data,  namely 
the  three  most  abundant  and  the  two  least  abundant  species  identified. 


Chemical  species 

Mass 

Phosphoric  acid 

338g 

Hydrogen  chloride 

10g 

Benzene 

13.7gg 

Butene 

Butdiyne 

■  0.004gg 

Table  1  -  Most  and  least  abundant  airborne  products  of  L84A1 

5.  HEALTH  AND  SAFETY  DATA 


The  toxicity  testing  guidelines  recommend  the  use  of  work  place  occupational  exposure 
limits  (OELs)  for  chemicals  as  the  basis  for  the  safety  assessment.  For  the  purposes  of  this 
assessment,  the  health  and  safety  data  was  extracted  from  [3]. 


[3]  details  exposure  limits  for  the  majority  of  the  species  identified  in  the  analysis  of  the 
L84A1.  This  is  given  in  terms  of  either  the  Short  Term  Exposure  Limit  (STEL),  or  the 
Time  Weighted  Average  (TWA).  The  STEL  concentration,  is  the  specified  concentration 
limit  that  can  be  tolerated  for  a  time  interval  of  15  minutes  and  the  TWA  concentration  is 
the  concentration  limit  permitted  for  a  period  of  8  hours.  In  order  that  comparisons  with  the 
safety  limits  can  be  made,  each  of  these  concentration  limits  need  to  be  transformed  to  a 
dosage,  as  this  takes  into  account  both  concentration  and  duration  of  exposure.  The 
following  example  considers  how  to  make  such  a  comparison. 

The  dosage  D  experienced  at  a  given  point  (x,y,z)  is  defined  as  follows; 

D(x,y,z)  =  jc(x,y,z,t).dt  (1) 

screen  _  duration 

where  c  is  the  mass  concentration  at  the  point  (x,y,z)  and  t  is  time. 

The  STEL  is  the  concentration  permitted  for  15  minutes,  therefore  the  dosage  exposure 
limit,  Dstel,  is  given  by; 

Dstel  =  Cstel  •  1 5  minutes  (2) 

where  Cstel  represents  the  STEL  concentration  limit. 

The  dosage  D,  at  any  point  can  thus  be  compared  with  the  exposure  limit  dosage  Dstel 
determined  above,  in  order  to  make  a  safety  assessment. 

Table  2  contains  information  on  the  three  most  abundant  chemical  species  produced  from 
the  combustion  of  the  L84A1  grenade.  For  each  species,  the  OEL  data  (either  STEL  or 
TWA  concentration  limit)  and  an  estimated  concentration  (assuming  that  the  total  mass  of 
that  species  were  produced  instantly  and  uniformly  distributed  throughout  a  sphere  of  lm 
radius)  are  given.  The  estimated  concentration  is  indicative  of  the  maximum  likely 
concentration  levels  that  might  be  experienced  in  the  vicinity  of  the  event.  This  value  is  an 
upper  estimate  for  concentration  as  the  payload  will  be  dispersed  over  a  disc  on  the  ground, 
typically  of  radius  5m.  Furthermore,  the  payload  will  burn  for  a  given  duration,  whereas 
this  calculation  assumes  that  all  the  screening  material  is  produced  instantly.  The  use  of  this 
worst  case  scenario  ensures  that  no  potentially  hazardous  species  were  ignored.  This 
process  was  completed  for  all  the  chemical  species  identified,  although  only  the  three  most 
abundant  species  are  shown  in  table  2. 


Species 

Mass 

OEL 

mg/m3 

Estimated  Initial 
concentration 
mg/m3 

Phosphoric  acid 

338g 

2  (STEL) 

8  x  104 

Hydrogen  chloride 

10g 

7.6  (STEL) 

2  x  103 

Benzene 

13.7pg 

16  (TWA) 

3  x  1 0'3 

Table  2  -  Concentration  of  the  most  abundant  species  produced  by  the  L84A1 

By  comparison  of  the  estimated  initial  concentration  with  the  OEL  figure,  it  is  possible  to 
rank  the  species  in  order  of  the  hazard  they  pose.  Any  chemical  species  whose  likely 
maximum  concentration  is  orders  of  magnitude  lower  than  the  threshold  OEL  concentration 
can  be  neglected  from  further  consideration.  Any  species  whose  maximum  concentration  is 
similar,  or  greater,  than  the  limiting  threshold  must  be  considered  further.  This  is  justified 
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on  the  grounds  that  any  controls  set  in  place  to  safeguard  against  the  greatest  threats  will 
necessarily  give  protection  against  the  lesser  threats. 

From  table  2,  it  can  be  seen  that  the  overall  assessment  problem  reduces  to  investigating 
two  species,  namely  phosphoric  acid  and  hydrogen  chloride,  as  these  are  the  only  products 
with  estimated  concentrations  greater  that  the  appropriate  STEL  limit.  The  problem  can  be 
reduced  further  because  not  only  is  phosphoric  acid  present  in  greater  quantities  than 
hydrogen  chloride,  it  is  also  subject  to  a  lower  OEL.  Thus  controls  set  in  place  for 
phosphoric  acid  will  necessarily  be  sufficient  for  hydrogen  chloride. 

According  to  [3],  for  phosphoric  acid; 

Cstel  =  2  mg.m 3  (3) 

Thus  the  STEL  dosage  limit  for  phosphoric  acid  can  be  calculated  according  to  equation  2; 

Dstel  =  0.0018  kg.m  3.s  (4) 

It  is  worth  noting  that  the  actual  values  chosen  for  safe  exposure  limits  will  depend  on  the 
proposed  mode  of  use  of  the  munition.  However,  once  concentration/dosage  maps  have 
been  generated,  the  variation  of  safety  distance  with  exposure  limit  and  mode  of  operation 
can  be  explored.  The  scope  of  this  paper  purely  considers  safety  in  accordance  with  the 
STEL  threshold. 

6.  ATMOSPHERIC  TRANSPORT 

The  previous  section  determined  the  concentration  and  dosage  limits  for  the  primary 
inhalation  hazard,  which  was  shown  to  be  phosphoric  acid.  To  physically  conduct  a 
toxicological  assessment  for  the  range  of  meteorological  conditions  in  which  the  munition 
will  be  used  is  impractical.  Therefore,  to  assess  the  dispersion  of  the  hazardous  species  the 
use  of  numerical  simulation  is  invoked,  namely  the  SCIPUFF  model. 

SCIPUFF  (Second  Order  Closure  Integrated  PUFF)  is  a  Lagrangian  transport  and  diffusion 
model.  This  model  is  a  component  of  the  Hazard  Prediction  and  Assessment  Capability 
(HP  AC)  developed  by  the  Defense  Threat  Reduction  Agency  (DTRA)  of  the  US.  HP  AC  is 
primarily  designed  for  the  hazard  assessment  of  nuclear,  chemical  and  biological  incidents 
and  is  claimed  to  be  good  for  ‘nearly  any’  atmospheric  incident.  Chemical,  biological  and 
nuclear  materials  can  be  hazardous  in  extremely  low  concentrations,  thus  the  model  is 
designed  to  predict  atmospheric  transport  from  releases  over  large  time  intervals  and 
distances  (i.e.  several  hours  and  hundreds  of  km’s).  Although  the  assessment  of  the  L84A1 
grenade  has  been  reduced  to  predicting  the  dispersion  of  a  single  species,  SCIPUFF  is 
equally  capable  of  modelling  the  combined  effect  of  many  components  when  no  single 
species  is  dominant. 

SCIPUFF  facilitates  input  of  a  comprehensive  range  of  scenario  description  parameters, 
while  its  fundamental  output  is  a  3  dimensional,  temporally  variant  concentration  map. 
Integrating  throughout  the  screen  duration,  dosage  at  any  point  can  be  determined.  The 
output  also  incorporates  a  probabilistic  component  to  account  for  random  atmospheric 
fluctuations.  The  UK  executed  a  series  of  field  trials  to  confirm  the  validity  of  the 
application  of  SCIPUFF  to  this  short  range  domain. 


A  safety  assessment  is  made  by  inspection  of  the  downwind  dosage  variation.  Based  on 
toxicological  considerations,  the  minimum  safe  distance  from  the  detonation  point  is  where 
D(x,y,z)  is  equal  to  Dstel-  At  this  point  the  dosage  received  is  at  the  limit  and  therefore 
only  one  such  exposure  could  be  tolerated.  Moving  further  downwind,  the  dosage 
decreases,  therefore  a  number  of  such  exposures  as  given  by  Ds'n:i/D(x,y,z)  may  be 
tolerated.  This  type  of  analysis  would  be  used  to  determine  a  safe  distance  for  a  trainer  who 
may  have  to  be  present  at  many  such  incidents,  although  as  the  dosages  become  lower  a 
more  appropriate  limit  may  be  selected  such  as  the  TWA. 

To  quantify  the  hazards  from  a  single  grenade,  simulations  were  carried  for  a  number  of 
meteorological  conditions.  The  range  of  conditions  encountered  considered  variations  in 
wind  speed  and  atmospheric  stability.  The  grenade  was  approximated  to  a  point  source 
evolving  the  airborne  products  uniformly  for  30  seconds  from  ground  level. 

The  following  figures  relate  to  the  dispersion  of  phosphoric  acid  at  a  height  of  1.8m  for 
moderate  weather  conditions;  namely  a  wind  speed  of  4.1ms'1  (along  the  x  axis)  and  neutral 
stability  conditions.  Figure  2  shows  the  mean  H3PO4  concentration  map  corresponding  to 
120  seconds  after  detonation  of  the  grenade.  (Note:  the  black  triangle  represents  the 
detonation  point.) 
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Figure  2  -  Mean  H3PO4  concentration  map  at  t=120  seconds 

Integrating  over  the  duration  of  the  screen,  figure  3  is  the  phosphoric  acid  dosage  map,  with 
an  automatic  scaling  of  the  contour  levels. 
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Figure  3  -H3PO4  dosage  map  (autoscale) 


Figure  4  presents  the  same  data  set  as  figure  3,  but  on  an  expanded  scale  and  with  a  single 
threshold  level  set  equal  to  DStel-  Therefore,  the  shaded  area  of  figure  4  indicates  where  the 
exposure  safety  limit  is  exceeded. 


Figure  4  -  H3PO4  dosage  map  (single  threshold  equal  to  Dstei) 

7.  DISCUSSION 

This  report  has  outlined  the  UK  toxicological  hazard  assessment  techniques,  using  the 
L84A1  hand  thrown  smoke  grenade  as  an  example. 

The  first  stage  of  the  assessment  requires  identification  and  quantification  of  all  airborne 
products  of  combustion.  This  was  achieved  by  direct  analysis  of  the  smoke  cloud  using  a 
Parr  bomb  system  to  contain  all  the  products  of  combustion.  A  total  of  34  species  were 
identified  as  airborne  products  of  combustion.  Two  species  were  found  to  be  dominant 
namely  H3PO4  and  HC1,  although  this  in  itself  is  not  grounds  neglecting  the  other  species. 
In  order  to  reduce  the  number  of  species  to  be  considered,  an  estimation  of  initial 
concentration  was  made,  and  compared  with  the  corresponding  OEL.  Any  species  whose 
estimated  concentration  was  significantly  less  than  the  OEL  was  neglected  from  further 
consideration.  The  results  of  this  technique  highlighted  than  H3PO4  was  the  primary  threat 
and  that  controls  set  in  place  for  this  would  be  sufficient  to  protect  against  the  other 
chemicals  identified. 

SCIPUFF  was  used  to  model  the  atmospheric  transport  of  H3PO4,  under  a  range  of 
atmospheric  conditions.  Variations  in  atmospheric  stability  and  wind  speed  were  shown  to 
have  significant  effect  on  safety  templates.  As  an  example  of  this  assessment,  figures 
relating  to  a  wind  speed  of  4.1ms"1  with  neutral  atmospheric  stability  were  presented. 
Figure  4  shows  that  under  these  conditions  the  minimum  safe  downwind  distance  in 
relation  the  inhalation  of  the  airborne  products  is  approximately  35m.  At  this  distance  only 
one  exposure  could  be  tolerated.  However,  if  more  exposures  were  expected,  the  dosages 
maps  could  yield  the  distance  at  which  a  number  of  munitions  could  be  tolerated  (although, 
this  would  not  necessarily  use  the  same  OEL  threshold). 

An  assessment  structured  along  the  guidelines  outlined  in  this  paper  will  help  in  the 
development  of  procedures  to  control  the  risk,  by  the  use  of  appropriate  personal  protective 
equipment  and  restrictions/guidelines  on  usage. 


It  must  be  emphasised  that  interpretation  of  the  inhalation  assessment  of  the  L84A1  hand 
thrown  smoke  grenade  is  subject  to  ratification  by  the  UK  medical/toxicological  authority. 


8.  CONCLUSIONS 


This  paper  has  demonstrated  how  the  UK  use  a  combination  of  laboratory  analysis 
techniques  and  numerical  simulation  methods,  in  conjunction  with  OELs,  as  the  foundation 
of  a  toxicological  hazard  assessment  process  for  obscurant  munitions.  The  end  product  of 
this  process  is  a  series  of  safety  templates,  such  that  the  exposure  thresholds  are  not 
exceeded  for  a  range  of  likely  meteorological  conditions.  In  conducting  such  an  assessment, 
consideration  needs  to  be  given  to  the  following  areas: 

•  Personnel  to  be  exposed  (military  or  civilian) 

•  Number/frequency  of  exposures  (trainer  v  trainee) 

•  Political  circumstance  (regular  occurrence  or  ‘one  off) 

The  issues  raised  by  these  topics  will  effect  the  chosen  safety  limit,  for  e.g.  STEL  or  TWA. 
Depending  on  the  current  political  climate  and  the  proposed  region  of  use,  consideration  of 
the  various  circumstances  listed  above,  may  determine  that  the  published  occupational 
exposure  limits  are  not  the  most  appropriate  threshold  to  determine  the  safe  operating 
conditions  relating  to  the  use  of  obscurant  systems.  However,  even  in  such  a  case,  the 
process  would  remain  the  same  and  would  simply  require  substitution  of  the  appropriate 
limiting  dosage  threshold. 

Once  the  inhalation  risk  has  been  considered,  other  hazards  to  personnel  and  the 
environmental  issues  need  to  be  considered,  in  order  to  complete  the  toxicological  and 
environmental  impact  assessment. 
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Abstract _ 

Formulating  and  analyzing  guided  weapon  concepts  to  meet  user  needs  is  both  an  art  and 
a  science.  Choices  made  for  certain  subsystems  impact  the  selection  and  design  of  other 
subsystems,  dictating  the  need  for  an  integrated  approach.  It  is  clear  that  the  sequence 
and  method  used  for  model  development  or  modification  must  be  carefully  chosen  to 
account  for  subsystem  interaction  in  order  to  minimize  subsystem  model  redesign. 
Additionally,  optimal  choice  of  simulation  runs  is  important  during  the  concept 
formulation  phase  as  well  as  during  the  final  evaluation  phase  for  weapon  concept 
comparisons  to  best  aid  the  selection  and  adjustment  of  design  parameters. 

A  methodology  has  been  developed  for  guided  weapon  concept  formulation,  modeling, 
and  analysis.  The  perspective  is  from  the  standpoint  of  a  government  laboratory  that  is 
developing  new  guided  munition  technology.  The  focus  is  not  on  detailed  weapon 
design,  but  rather  on  high-level  concept  design,  that  allows  comparison  and  selection  of 
one  or  more  concepts  for  a  more  detailed  design  later.  The  methodology  addresses  the 
functional  interaction  of  all  weapon  subsystems  and  follows  a  sequential  design.  The 
result  is  a  non-optimal,  but  highly  useful  solution,  which  looks  at  concept  viability.  The 
methodology  also  addresses  simulation-generated  data  used  in  the  design  process  and  in 
the  ultimate  analysis  process  to  compare  performance  with  user  requirements. 

1.  Introduction _ 

At  the  Air  Force  Research  Laboratory’s  Munitions  Directorate,  located  at  Eglin  AFB, 
Florida,  the  Guidance  Simulation  Branch  of  the  Ad  vanced  Guidance  Division 
(AFRL/MNGG)  is  responsible  for  analyzing  the  effect  of  evolving  laboratory 
technologies  on  the  performance  of  existing  and  conceptual  air-launched  guided 
munitions.  Simulation  development  at  AFRL/MNGG  is  accomplished  using  the  recently 
developed  MSTARS  (Munition,  Simulation  Tools  and  Resources)  Simulation  System1,  a 

1  For  more  information  on  MSTARS,  contact  Mr.  Scott  Hess  at  (850)  882-8195  ext.  3282  or 


visual  simulation  environment,  which  contains  a  repository  of  munition  component 
models.  The  visual  environment  and  the  repository  perfectly  suit  the  needs  of 
AFRL/MNGG  because  they  enable  simulations  to  be  developed  rapidly  based  on 
prototype  system  components  that  can  be  modified  as  needed  to  meet  customer 
requirements.  Additionally,  the  visual  environment  provides  an  intuitive  feel  of  how  the 
simulation  components  work  together.  Figure  1  shows  the  user  interface  presented  at  the 
MSTARS  munition  diagram  level. 
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Figure  1.  MSTARS  Munition  Model  Components 


AFRL/MNGG  customers  are  often  working  on  technologies  for  use  in  future  weapon 
systems.  Performance  requirements  for  these  systems  are  often  vague  and  incomplete. 
Such  requirements  typically  include  high-level  operational  requirements  such  as  launch 
range,  and  include  high-level  physical  constraints  such  as  weight  and  size.  The  vague 
nature  of  requirements  at  this  level  allows  much  leeway  for  design  creativity  in  the 
simulation  process. 

Results  from  a  recent  in-house  concept  study2  performed  by  AFRL/MNGG  indicate  that 
to  accomplish  successful  risk  reduction  in  the  formative  stages  of  concept  development 
through  simulation,  it  is  necessary  to  address  the  simulation  development  and  analysis 
process  from  a  structured  systems  approach.  There  are  four  key  principles  inherent  in  the 
activities  relating  to  this  approach: 


2  Miniaturized  Munition  Capability  (MMC)  Analysis  of  Alternatives  (AoA)  Concept  Study,  AAC/DRPW 
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1 .  Understand  the  requirement.  The  design,  development,  and  integration  of 
simulation  models  is  tightly  coupled  with  the  operational  requirements  and 
constraints  imposed  by  the  warfighter.  Therefore,  it  is  necessary  to 
understand  all  munition  operational  requirements  before  any  simulation 
development  is  initiated. 

2.  Use  a  structured  simulation  development  methodology.  A  well  defined,  well 
structured  methodology  is  crucial  to  building  an  effective  simulation  model 
and  to  building  an  efficient,  smoothly  operating  simulation  development  team. 
This  is  true  regardless  of  whether  the  development  environment  is  visual  or 
code-based. 

3 .  Emphasize  reusable  simulation  components.  Simulation  development 
should  rely  heavily  on  model  reuse  and  shared  data  to  reduce  cost,  reduce 
errors  due  to  building  components  from  scratch,  save  time,  and  to  prevent 
model  incompatibilities. 

4.  Select  analyses  appropriate  to  evaluating  critical  performance  requirements. 
Thousands  of  meaningless  simulation  runs  are  no  better  than  zero  simulation 
runs.  Only  certain  high  level,  but  critical,  performance  characteristics  can  be 
evaluated  for  a  conceptual  munition.  The  simulations  conducted  and  the 
subsequent  analyses  must  be  tailored  and  focused  on  answering  specific 
questions  about  the  critical  performance  issues. 

In  order  to  put  any  concept  analysis  methodology  in  perspective,  it  is  necessary  to 
understand  the  “big  picture”.  The  problem  domain,  being  addressed  here,  is  the 
development  of  munition  concepts.  The  concepts  meet  user  requirements  and  can  be 
provided  to  other  organizations  for  further  refinement,  actual  end  item  development,  and 
production.  The  elements  of  the  big  picture  are  addressed  in  Section  2. 

Simulation  and  analysis  are  critical  elements  of  Munition  Concept  Exploration  process, 
as  described  in  Section  2.  To  address  these  critical  elements,  AFRL/MNGG  has 
developed  a  structured  approach,  making  use  of  in-house  tools  and  a  visual  simulation 
system.  The  methodology  is  described  in  Section  3  and  embodies  the  four  key  principles 
discussed  earlier. 
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2.  The  Big  Picture 


Figure  2  is  the  authors’  depiction  of  a  generic  group  of  activities,  which  occur  from  the 
point  where  the  warfighter  defines  a  requirement  through  the  process  of  munition  concept 
exploration.  The  boxes  shown  in  the  diagram  do  not  represent  any  specific  DoD,  Air 
Force,  or  AFRL  process.  The  depiction  was  created  by  the  authors  for  convenience  to 
describe  generic  processes  that  could  represent  a  number  of  different  situations  where 
concept  exploration  occurs. 

The  Munition  Concept  Development  Process  is  the  sequence  of  activities,  resulting  in 
one  or  more  candidate  munition  concepts.  The  concepts  are  provided  to  a  SPO  or  other 
organization  for  final  concept  selection,  development,  and  production.  The  overall 
process  is  depicted  as  being  comprised  of  two  broad  sub-processes:  (1)  Requirements 
Definition  and  (2)  Munition  Concept  Exploration.  These  two  processes  have  been  further 
divided  into  a  series  of  sequential  overlapping  phases,  adapted  from  the  well-known 
Modified  Waterfall  Model,  which  allows  a  return  to  previous  phases  if  needed.  The 
following  sections  describe  each  phase. 


Figure  2.  Munition  Concept  Development  Process 
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2. 1  Warfighter  Requirements  Phase 


The  Requirements  Definition  process  begins  with  the  Warfighter  Requirements  Phase, 
which  defines  the  mission  level  requirements  of  the  warfighter  from  launch  to  impact  of 
the  weapon  system.  This  phase  takes  a  problem-oriented  approach  in  describing  the 
mission  need  in  broad  terms,  as  shown  in  Figure  3.  The  operational  command,  the  owner 
of  the  phase,  is  continuously  evaluating  the  current  weapon  systems  against  the  ever- 
changing  threat  environment.  If  the  threat  changes  significantly  so  that  the  current 
systems  are  unable  to  counter  it  with  a  change  in  doctrine,  tactics,  training  or 
organization,  then  the  operational  command  generates  a  new  requirement,  which  is 
specified  in  a  Mission  Needs  Statement  (MNS).  A  typical  MNS  may  address  such  areas 
as: 


•  Multiple  kills  per  pass 

•  Multiple  ordnance  carriage 

•  Adverse  weather  capability 

•  Medium-to-high  altitude  accuracy 

•  Capability  against  hard  targets 

•  Carriage  on  multiple  aircraft 
(e.g.  F-15,  F-16,  F-18,  F-117,  B-2) 

•  Increased  effectiveness 

•  Reduced  susceptibility  to  countermeasures 


Figure  3.  Warfighter  Requirements 


2.2  Munition  Operational  Requirements  Phase 

The  warfighter  requirements  are  further  refined  during  the  Munition  Operational 
Requirements  Phase,  which  refines  the  MNS  from  broad  statements  into  more  specific 
munition  operational  requirements.  This  phase  is  solution-oriented:  it  describes  a 
detailed  approach  to  solving  the  warfighter  mission  needs  problem.  The  Operational 
Requirements  Group,  which  could  be  one  of  several  organizations,  addresses  mission 
needs  from  all  aspects  of  operation  across  the  entire  life  cycle  of  the  system;  and  is 
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ultimately  responsible  for  the  development  of  the  new  munition  system.  The  group  must 
gain  a  sound  understanding  of  the  warfighter  needs,  to  achieve  a  proper  balance  between 
cost,  schedule,  and  performance  considerations.  The  Operational  Requirements  Group 
produces  the  Operational  Requirements  Document  (ORD),  which  specifies  requirements 
for  such  things  as: 


•  Aircraft  integration  issues 

•  Cost  and  scheduling 

•  Survivability 

•  Effectiveness 

•  Threats 

•  Performance 

•  Logistics 

•  Mission  planning 

•  Load-outs 


Operational  Requirements  Group 

Performance 

CONOPS 

Effectiveness 

Logistics 


Figure  4.  Operational  Requirements 


The  Operational  Requirements  Group  assembles  other  commands  to  investigate  the 
issues  laid  out  in  the  ORD.  Sufficient  data  is  collected  from  the  commands  so  that  a 
recommendation  for  a  new  weapon  system  can  be  made  to  the  warfighter. 

This  phase  marks  the  end  of  the  Requirements  Definition  process.  The  resulting 
requirements  are  extremely  important  to  the  subsequent  concept  formulation  and 
analysis,  detailed  in  Sections  2.3  and  2.4. 


2.3  Concept  Brainstorming  Phase 

The  Concept  Brainstorming  Phase  marks  the  beginning  of  the  Munition  Concept 
Exploration  process.  This  process,  the  main  interest  of  this  paper,  takes  the  previously 
developed  requirements  and  ultimately  transforms  them  into  effective  candidate  munition 
concepts,  which  could  meet  user  needs. 
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The  purpose  of  the  Concept  Brainstorming  Phase  is  to  match  munition  subsystem  design 
choices  against  performance  requirements,  and  to  eventually  identify  one  or  more 
munition  concept  prototypes  suitable  for  further  study  using  simulation.  The  munition 
operational  requirements  will  impose  restrictions  on  the  type  of  guidance  law,  autopilot, 
navigation  system,  airframe,  and  propulsion  system,  which  could  be  selected  for  use.  The 
Concept  Brainstorming  Team  identifies  all  applicable  technologies  (Figure  5),  selects 
those  that  best  suit  the  requirements,  and  integrates  them  to  form  one  or  more  “paper 
munitions”  that  meet  the  performance  requirements.  It  is  desirable  that  there  be  several 
“paper  munition”  concepts  that  meet  the  requirements.  Each  munition  concept  is  defined 
in  sufficient  detail  such  that  the  Simulation  Development  Team,  the  next  players  in  the 
process,  will  have  a  meaningful  starting  point  for  building  a  simulation  of  the  concept. 
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Figure  5.  Munition  Subsystem  Technologies 


Although  simulation  has  not  been  mentioned  as  a  part  of  this  stage,  often  the  paper  study 
is  refined  with  the  aid  of  high  level  simulation  tools,  such  as  three-degree-of-freedom 
(DOF)  simulations.  These  high  level  tools  aid  in  verifying  preliminary  concept  design 
prior  to  initiating  the  Simulation  Development  Phase. 
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2.4  Simulation  Development  Phase 


In  the  Simulation  Development  Phase,  the  “paper  munition”  concepts,  resulting  from  the 
previous  phase,  serve  as  the  blueprint  for  the  concept  simulation  models.  An  organized 
development  approach  is  used  and,  in  the  case  for  AFRL/MNGG,  existing  components 
within  the  MSTARS  library  are  pulled  together  to  form  a  prototype.  The  component 
models  are  exchanged  and/or  modified  to  satisfy  the  munition  operational  requirements. 
Figure  6  gives  an  example  of  a  typical  simulation  and  its  associated  technology 
components. 


Simulation  Development 
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Figure  6.  Simulation  Development 


To  improve  the  effectiveness  and  efficiency  of  the  simulation  development  procedure, 
MNGG  has  developed  a  structured  methodology,  which  uses  in-house  software  tools. 

For  each  concept,  the  simulation  developed  is  much  more  detailed  than  a  3-DOF 
simulation,  which  might  have  been  used  in  the  previous  phase.  The  methodology  and  the 
simulation  development  activities  are  described  in  detail  in  Section  3.1. 

2.5  Concept  Analysis  Phase 

The  last  phase.  Concept  Analysis,  provides  an  in-depth  study  of  the  munition  concept 
performance  capabilities.  The  purpose  is  to  demonstrate  the  general  capabilities  of  the 
concept  and  to  verify  that  critical  warfighter  requirements  have  been  met.  Additionally, 
comparative  simulation  results  are  used  to  rank  the  concepts  defined  by  the  Concept 
Brainstorming  Team. 
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It  is  critical  that  appropriate  analysis  objectives  be  defined,  which  are  keyed  to  questions 
about  munition  performance.  Analysis  planning,  which  is  initiated  in  the  Simulation 
Development  Phase,  is  important  to  determine  the  requirements  for  simulation  fidelity, 
identification  of  analysis  data,  and  simulation  functional  requirements  (such  as  multi-run 
capability).  More  details  about  this  phase  are  found  in  Section  3.1. 

After  preliminary  analysis,  the  Concept  Brainstorming  Team  may  find  it  necessary  to 
correct  the  original  concept  specifications  due  to  design  errors  that  were  not  evident 
during  the  Concept  Brainstorming  Phase.  Other  concepts  may  drop  out  of  consideration 
altogether  due  to  extreme  poor  performance.  The  remaining  concepts  are  further 
evaluated  and  the  results  are  used  to  rank  the  concepts  with  respect  to  performance 
capability  relative  to  tire  requirements.  It  should  be  noted  that  cost  analysis,  a  critical 
activity,  is  conducted  during  this  phase.  However,  the  performance  aspect  of  the  analysis 
process  is  the  focus  of  this  paper. 
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3,  Structured  Design  and  Analysis  Methodology 


The  structured  methodology  begins  during  the  Concept  Brainstorming  Phase.  The 
methodology  encompasses  the  four  principles  discussed  in  Section  1 .  The  Concept 
Brainstorming  Team  (Section  2.3)  uses  the  specifications  generated  during  the  Munition 
Operational  Requirements  Phase  to  develop  a  single,  or  set  of  alternative  munition 
concepts.  Each  requirement  will  result  in  some  notional  ideas  from  the  team  regarding 
subsystem  technologies,  which  could  be  used  to  help  the  munition  meet  the  requirement. 
Subsystem  technology  selections  may  be  mutually  exclusive  or  may  result  in  degraded  or 
enhanced  performance  when  used  together.  Thus,  there  are  many  factors  to  consider.  An 
organized  approach  is  useful  to  ensure  that  all  critical  issues  have  been  considered. 
Quality  Functional  Deployment  (QFD)  or  other  such  approaches  can  be  extremely 
helpful  in  determining  a  meaningful  set  of  concepts. 

The  MNGG  approach  does  not  require  any  specific  technique  at  this  time  for  generation 
of  the  munition  concepts.  However,  the  result  should  be  one  or  more  concepts,  which  are 
capable  (from  a  gross  perspective)  of  meeting  user  requirements.  Several  steps, 
accomplished  during  the  Concept  Brainstorming  Phase  to  arrive  at  the  munition  concepts, 
are  repeated  in  greater  detail  during  the  Simulation  Development  Phase. 

Most  of  the  methodology  and  tools  developed  by  AFRL/MNGG  fells  in  the  simulation 
development  and  analysis  areas.  Section  3.1  describes  the  Simulation  Development 
Approach  and  Section  3.2  covers  the  Analysis  Approach. 


3.1  Simulation  Development  Approach 

The  activities  described  in  this  section  are  directly  applicable  to  the  Simulation 
Development  Phase  described  in  Section  2.4. 

To  construct  the  simulation  of  a  concept,  it  is  useful  to  look  at  the  munition  from  both  a 
functional  point  of  view  and  from  an  object-oriented  point  of  view. 

A  functional  decomposition  of  the  munition’s  operational  modes  separates  the  primary 
system  functions  into  successively  more  detailed  processes  and  defines  the  data  flow 
between  the  processes.  It  provides  good  visibility  into  the  various  critical  processes, 
which  occur  during  weapon  flyout.  For  example,  a  flight  profile  for  a  typical  air-to- 
surfece  smart  weapon  can  be  partitioned  into  five  modes  of  operation: 

•  Pre-launch 

•  Post-launch 

•  Mid-course 

•  Pre-terminal 

•  Terminal 
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The  functions  performed  during  each  flight  mode  are  examined  to  highlight  overall 
simulation  requirements  and  subsystem  interaction,  based  on  performance  requirements 
of  interest.  Analysis  of  these  flight  modes  can  also  suggest  simulation  architecture  design 
decisions,  which  can  make  the  simulation  model  more  intuitive  and  effective. 

Based  on  the  desired  performance  analysis  to  be  conducted,  a  description  of  data 
requirements,  including  inputs  and  outputs,  should  be  formulated.  A  description  of  the 
data  should  include  the  volume  and  frequency  of  data  to  be  processed,  as  well  as  any 
specific  formats  and  limitations.  These  data  requirements  are  critical  to  the  success  of  the 
Concept  Analysis  Phase,  discussed  in  Section  2.5. 

An  object-oriented  view  of  the  simulation,  combined  with  the  concept  hierarchy,  will 
provide  insight  into  the  subsystem  model  requirements.  A  Requirements  Traceability 
Matrix  (RTM)  is  produced  during  the  Concept  Brainstorming  Phase,  to  ensure  that 
selection  of  technologies  and  subsystems  relate  to  the  munition  requirements.  The  RTM 
is  further  used  during  simulation  development  to  identify  requirements  for  the  munition 
subsystem  models  and  the  simulation  architecture. 

Building  the  simulations  is  greatly  aided  by  using  a  library  of  reliable,  reusable 
subsystem  model  components.  The  library  components,  created  over  years  of  simulation 
development,  have  been  through  an  extensive  design,  testing,  and  validation  process. 

The  result  is  a  savings  in  overall  design  time  by  maximizing  model  reuse.  The  best 
starting  point  for  a  model  prototype  is  a  complete,  existing,  operational  munition  model, 
which  has  the  same  functional  characteristics  and  many  related  subsystems  as  the 
intended  final  concept.  A  top-level  description  of  this  process  is  given  in  Figure  7. 

One  of  the  critical  activities  that  must  be  accomplished  is  identification  of  the  subsystems 
of  the  model  prototype  that  requires  modification  in  order  to  meet  system  requirements. 
Redesign  may  not  necessarily  involve  the  restructuring  of  an  existing  model,  but  may 
only  require  modification  of  model  attribute  data,  such  as  aerodynamic  or  thrust  data.  In 
any  event,  a  sequence  order  for  redesign  must  be  established  to  minimize  the  need  for 
redesigning  subsystem  models  repeatedly. 
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Figure  7.  Simulation  Development  Process 


A  procedure  to  determine  the  subsystem  modification  sequence  has  been  translated  into 
an  AFRL/MNGG  in-house  software  utility  called  the  Module  Selector  Tool  (MST).  The 
MST  provides  an  automated  means  to  establish  the  optimum  sequence  order  that 
component  modules  should  be  modified.  The  MST  allows  the  user  to  select  a  set  of 
munition  subsystem  components,  specify  the  components  that  will  require  modification, 
and  determine  the  sequence  in  which  the  modifications  should  occur.  It  is  important  to 
note  that  the  procedure  works  for  a  collection  of  existing  models  and  will  not  address 
missing  technologies  or  components.  The  user  may  find  it  necessary  to  include  a 
“placeholder”  for  a  missing  component,  ascertain  its  influences  on  other  components,  and 
then  reconfigure  the  MST. 

Figure  8  shows  a  screen  shot  of  the  Module  Selector  Tool,  which  consists  of  four  panels: 
the  Module  Selector,  the  Edit  Selection,  the  Dependency  Matrix,  and  the  Output  panels. 

The  first  user-input  panel,  the  Module  Selector  (Figure  8),  consists  of  an  itemized  list  of 
munition  subsystem  components  contained  in  the  MSTARS  library.  The  components  are 
generic  enough  to  allow  the  user  to  create  a  functional  prototype  munition.  The  Edit 
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Selection  panel,  also  a  user-input  routine,  enables  the  user  to  specify  the  components  that 
may  require  modification  in  order  to  meet  functional  requirements.  Associated  with  each 
component  is  a  “dependency  bin”  that  sums  the  effects  of  modifying  dependent 
components.  The  logic  for  determining  the  dependencies  results  from  a  heuristic 
approach  and  requires  knowledge  of  the  functional  dependencies  of  the  models.  If  a 
component  is  selected  for  modification,  then  a  value  of  1  is  added  to  the  dependency  bin 
of  every  component  affected  by  the  modification.  The  tally  is  used  to  “weight”  the 
components  and  to  determine  the  modification  order.  The  higher  the  number  associated 
with  a  component,  the  later  in  the  redesign  phase  it  falls,  thus  eliminating  adverse  affects 
on  a  previously  redesigned  component.  The  components  and  weights  appear  in  the 
Output  panel  as  well  as  on  an  additional  view  that  provides  a  sort  and  a  refit  schedule. 


Figure  6.  Module  Selector  Tool  (MST)  Screenshot 


The  Dependency  Matrix  panel  is  merely  a  graphical  representation  of  the  component 
dependencies  and  serves  as  a  sanity  check. 

When  the  modification  order  has  been  determined,  the  module  modification  procedure 
begins.  First,  the  library  component  is  retrieved  from  the  MSTARS  library.  The  module 
is  customized  to  reflect  the  requirements  and  specifications  obtained  in  the  Munition 
Operational  Requirements  Phase  (this  could  also  be  a  higher  level  requirement  generated 
earlier  in  the  overall  process).  After  all  changes  have  been  made,  an  independent 
reviewer  (e.g.  another  team  member)  is  asked  to  review  the  work.  The  reviewer  checks 
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for  errors  in  design,  format,  and  completeness.  This  step  is  necessary  because  it  gives  an 
outside  perspective  to  the  work.  If  no  discrepancies  were  found,  the  component  is  passed 
to  another  team  member  for  thorough  testing.  Here,  inputs,  chosen  so  that  each  branch  of 
the  module  is  executed,  are  fed  into  the  module.  The  actual  outputs  are  collected  and 
compared  against  expected  outputs  to  verily  that  the  component  is  operating  correctly.  If 
any  discrepancies  were  found,  the  module  is  sent  back  to  the  modification  step  for 
corrections.  The  procedure  continues  until  both  the  modification  and  testing  steps  are 
completed  successfully  for  all  components  that  were  marked  for  change  with  the  MST 
(refer  to  Figure  6). 

The  simulation  build  process  is  complete  when  all  modules  have  been  modified  and 
tested,  as  necessary.  The  simulation  is  built  by  successively  interfacing  related 
components.  For  example,  the  first  step  of  the  build  may  begin  with  the  guidance 
computer.  The  next  logical  component  addition  is  the  autopilot  since  the  outputs  of  the 
guidance  computer  are  the  inputs  to  the  autopilot.  After  each  new  component  is  added, 
tests  are  performed  to  ensure  that  the  integrated  components  are  working  together 
correctly.  This  procedure  continues  until  all  components  have  been  connected  together  to 
form  the  new  munition  model. 

The  last  stage  of  this  phase  is  simulation  verification  and  acceptance  testing.  The 
acceptance  tests  are  end-to-end  systems  level  tests  and  must  occur  prior  to  analysis. 

These  tests  check  the  basic  functionality  of  the  munition  system,  such  as: 

•  munition  stability 

•  guidance  and  navigation  accuracy 

•  propulsion  functionality 

•  other  similar  functions 

If  the  munition  model  fails  the  acceptance  tests  because  of  a  component  implementation 
error,  the  component  is  corrected,  tested,  and  integrated  by  following  the  procedure 
outlined  earlier.  If  the  failure  is  a  result  of  design  error,  the  error  is  isolated  and  a  re- 
evaluation  by  the  Concept  Brainstorming  Team  is  required. 

The  end  product  of  the  Simulation  Development  Phase  is  a  set  of  verified  simulations, 
representing  each  of  the  munition  prototypes  developed  by  the  Concept  Brainstorming 
Team. 
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3.2  Analysis  Approach 


The  activities  described  in  this  section  are  directly  applicable  to  the  Concept  Analysis 
Phase  described  in  Section  2.5.  To  accomplish  the  analysis,  the  simulation  is  exercised 
through  a  series  of  scenarios,  which  establish  performance  boundaries  and  capabilities. 


Simulation  &  Analysis 


Figure  7.  Simulation  and  Analysis 


The  areas  for  analysis  must  be  carefully  selected  based  on  the  performance  criteria, 
outlined  in  the  ORD.  In  feet,  the  performance  criteria  drive  the  fidelity  and  functional 
requirements  of  the  simulation.  For  this  reason,  the  identification  of  the  analysis 
requirements  is  accomplished  during  the  Simulation  Development  Phase.  Areas  for 
analysis  may  include: 

•  munition  minimum/maximum  range 

•  maneuver  capability 

•  terminal  performance  (i.e.  impact  velocity,  impact  angle,  and  miss  distance) 

•  operational  environment 

•  any  number  of  other  areas 

Based  on  the  initial  analysis  data,  additional  analysis  may  be  required  to  perform  trade¬ 
off  studies,  which  address  particular  system  components  and  their  impact  on  overall 
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performance.  The  trade-off  studies  provide  information  for  risk  reduction,  technology 
investment  decisions,  and  serve  to  refine  the  concept. 

All  performance  data  generated  from  the  simulation  and  analysis  effort  is  collected  and 
compiled  by  the  Operational  Requirements  Group.  The  data  is  used  to  reject 
unacceptable  concepts.  The  final  refined  concepts  and  performance  analysis  results  are 
typically  provided  to  a  SPO,  or  similar  organization,  for  use  in  selecting  one  or  more 
concepts  for  possible  development  and  production. 
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4.  Conclusion 


For  convenience  and  clarity,  MNGG  has  depicted  the  overall  concept  development 
process  as  consisting  of  two  sub-processes:  (1)  Requirements  Definition  and  (2)  Munition 
Concept  Exploration.  Activities  occurring  in  the  two  processes  have  been  mapped  into 
five  phases.  Concept  Exploration  has  three  phases,  and  it  is  in  the  latter  two  phases, 
involving  simulation  and  analysis,  where  MNGG  has  developed  an  organized 
methodology  and  in-house  tools  to  make  the  activities  more  efficient  and  effective. 

The  various  activities  of  the  simulation  and  analysis  methodology  employed  by  MNGG 
embody  four  key  principles: 

•  Understand  the  requirement. 

•  Use  a  structured  simulation  development  methodology. 

•  Emphasize  reusable  simulation  components. 

•  Select  analyses  appropriate  to  evaluating  critical  performance  requirements. 

In  the  course  of  developing  the  methodology,  MNGG  has  developed  in-house  software 
tools,  which  aid  in  making  the  simulation  development  and  analysis  more  effective. 

These  include: 

•  The  M STARS  Simulation  System 

•  The  Module  Selector  Tool  (MST) 

The  methodology  and  tools  were  developed  during  a  recent  major  effort  to  analyze  a  set 
of  munition  concepts.  Since  that  effort,  the  methodology  and  tools  have  been  further 
refined  and  are  continuing  to  evolve.  Practicing  such  a  methodology  and  using  effective 
tools  can  tremendously  reduce  the  time  required  to  conduct  munition  concept  analysis 
and  can  make  that  analysis  much  more  effective. 
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Abstract 

The  need  for  “smart”  munitions  that  minimize  collateral  damage  and  maximize  the  number  of 
kills  per  sortie  has  prompted  the  Air  Force  to  investigate  the  use  of  onboard  seekers  to  increase 
weapon  accuracy.  One  seeker  currently  under  consideration  is  a  staring  focal  plane  array 
LADAR  (“flash”  LADAR).  Before  beginning  an  acquisition  program  for  the  flash  LADAR, 
analysis  to  examine  its  feasibility  and  determine  preliminary  performance  requirements  was 
desired.  This  paper  discusses  the  simulation  environment,  methodology,  and  results  of  the 
analysis. 

* 

Introduction 

The  mission  of  attacking  both  high-value  fixed  and  moving  targets  through  the  use  of  a 
small  smart  bomb  (SSB)  is  currently  under  consideration  by  the  Air  Force.  A  typical  scenario 
for  a  direct  attack  mode  of  the  SSB  may  consist  of:  launch  from  a  standoff  distance  of  over  40 
miles;  non-powered,  wing-assisted  glide  into  target  area;  pitch-over  to  achieve  maximum  impact 
velocity;  and  finally  acquisition  of  the  target  by  a  terminal  seeker. 

Two  important  requirements  for  flash  LADAR  seeker  feasibility  are  update  rate  and 
field-of-view  (FOV).  Update  rate  is  defined  as  the  rate  at  which  the  seeker  and  signal  processor 
can  give  a  target  location  measurement  to  the  terminal  filter.  FOV  is  the  instantaneous  angle 
seen  by  the  staring  focal  plane  seeker.  Monte  Carlo  analysis  against  both  fixed  and  maneuvering 
targets  was  performed.  The  maneuvering  target  represented  a  missile  launcher  performing  an 
emergency-braking  maneuver.  A  6-DOF  simulation  representing  a  SSB  mission  against  these 
two  targets  was  rapidly  developed  using  an  in-house  modular  simulation  tools  and  resources 
(MSTARS)  methodology. 


MSTARS  is  a  visual  simulation  environment  using  the  product  VisSim  as  the 
programming  language.  Munition  components  are  developed  and  maintained  in  a  modular 
environment  that  enables  rapid  integration  of  subsystem  models  into  the  MSTARS  simulation 
architecture.  Using  this  system,  a  simulation  modeling  the  flash  LADAR  seeker  on  a  SSB  was 
put  together  in  a  matter  of  a  few  days. 

While  global  positioning  system  (GPS)  measurements  are  assumed  available  to  the  SSB, 
a  jammed  GPS  environment  was  used  for  comparison  purposes.  Other  error  sources  included 
typical  target  location  error  (TLE),  inertial  measurement  unit  (IMU)  noise,  and  seeker  noise. 

The  next  section  discusses  the  engagement  scenario  and  simulation  parameters  that  were  used  in 
the  analysis. 

Engagement  Scenario 

There  were  two  types  of  engagement  scenarios  under  consideration.  The  first  was  a  high- 
value  fixed  target  (HVFT),  while  the  second  consisted  of  a  missile  launcher  performing  a 
decelerating,  braking  maneuver  during  the  last  few  seconds  of  the  engagement.  To  save 
simulation  time,  no  large  standoff  range  was  used  for  this  analysis.  In  both  scenarios  the  target 
was  initially  located  at  20  km  downrange  from  the  munition  launch  point  with  no  cross-range 
location.  The  munition  was  launched  using  the  simulation  conditions  given  in  Table  1. 


TABLE -1 

Launch  and  Noise  Conditions 

Parameters 

(units) 

Unjammed 

Jammed  (~75  sec) 

Launch  Altitude 

(ft) 

40,000 

Unchanged 

Launch  Velocity 

(Mach) 

0.8 

Unchanged 

Seeker  Acquisition  Range  (m) 

1500 

Unchanged 

Seeker  Blind  Range 

(m) 

200 

Unchanged 

Desired  Impact  Angle 

(deg) 

85 

Unchanged 

Seeker  Range  Error 

(m) 

0.5 

Unchanged 

Seeker  Range  Rate  Error 

(m/s) 

0.05 

Unchanged 

Seeker  Angular  Error 

(rad) 

0.00067 

Unchanged 

A  single  initial  6-DOF  fly-out  to  seeker  acquisition  range  was  completed  using  no  noise 
or  error  sources  and  the  true  target  location.  The  munition  end-state  conditions  for  the  seeker 
acquisition  point  were  saved  and  used  to  initialize  all  future  runs.  The  statistical  errors 
associated  with  a  typical  GPS  inertial  navigation  system  (INS),  as  well  as  TLE  were  added  to  the 
true  target  location  to  simulate  the  errors  that  would  have  built  up  over  the  fly-out.  This  saved 
numerous  hours  of  simulation  time  and  allowed  the  study  to  be  completed  in  less  than  two 
weeks. 

The  SSB  was  modeled  as  a  250-pound  guided  munition.  It  is  shown  in  Figure  1  compared  with  a 
conventional  2000-pound  munition.  The  munition  guidance  system  used  against  the 
maneuvering  target  consisted  of  a  terminal  seeker,  extended  Kalman  filter  (EKF),  optimal 


guidance  law,  and  aero-adaptive  autopilot.  The  terminal  seeker  measured  range,  range-rate, 
azimuth,  and  elevation.  These  measurements  were  then  sent  to  the  EKF  at  various  update  rates 
to  produce  state  estimates  at  100-hertz  (Hz)  for  the  guidance  system.  Guidance  commands  were 
generated  and  transferred  to  the  autopilot  where  they  were  turned  into  three  fin  deflection 
commands.  In  the  case  of  the  HVFT  mission,  no  EKF  was  used  and  the  seeker  measurements 
were  used  directly  in  a  proportional  navigation  guidance  law. 


Figure  1.  Comparison  of  SSB  with  Mk-84 

In  the  HVFT  scenario,  the  target’s  location  was  assumed  known  to  within  a  typical  target 
location  error  (TLE).  Beginning  with  the  previously  saved  seeker-acquisition  end-state 
conditions,  the  SSB  was  flown  against  the  HVFT.  Each  run  set  consisted  of  31  Monte  Carlo 
runs  for  each  set  of  conditions.  TLE  and  GPS  errors  were  root-sum-squared  (RSS’d)  and  added 
to  the  true  target  location  at  the  beginning  of  each  Monte  Carlo  ran.  This  is  equivalent  to  the 
error  in  target  location  that  would  be  seen  by  the  seeker  upon  acquisition  in  a  full  fly-out 
scenario.  Figure  2  shows  the  target  position  errors  upon  seeker  acquisition  for  both  the  jammed 
and  unjammed  scenarios.  The  seeker  update  rates  used  were  100,  50,  20,  5,  and  1  Hz,  along  with 
a  one-look  only  case. 

The  maneuvering  target  case  was  slightly  more  complicated.  Again  the  target’s  initial 
location  was  assumed  known  to  within  a  typical  TLE.  However,  in  this  scenario  the  target  was 
given  an  initial  unknown  downrange  velocity  of  15  m/sec  at  the  start  of  seeker  acquisition.  It 
immediately  slammed  on  its  brakes  to  decelerate  to  zero  velocity  during  the  terminal 
engagement,  posing  a  stressing  guidance  problem. 
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Figure  2a.  Unjammed  target  locations  seen  by  seeker 
At  start  of  acquisition 
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Figure  2b.  Jammed  target  locations  seen  by  seeker 
At  start  of  acquisition 
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The  results  presented  here  are  for  both  the  HVFT  and  maneuvering  target  scenarios, 
using  unjammed  and  jammed  environments.  The  FOV  was  left  unconstrained  so  that  the 
maximum  values  encountered  for  the  various  scenarios  could  be  determined. 


Figures  3  through  6  show  the  resulting  HVFT  FOV  requirements  for  100  and  20  Hz 
update  rates;  jammed  and  unjammed  environments.  All  3 1  Monte  Carlo  runs  are  plotted  for  each 
update  rate  shown.  Plots  for  other  update  rates  showed  similar  trends.  The  maximum  FOV  grew 
slightly  and  the  individual  curves  differed  very  little,  as  update  rates  became  smaller.  Figure  7 
displays  the  effect  of  seeker  update  rate  on  miss  distance.  This  analysis  helped  to  confirm  the 
expectation  that  there  is  little  needfor  high  update  rates  when  attacking  stationary  targets.  The 
FOV  requirements  for  this  particular  type  of  target  were  also  bounded.  The  FOV  requirements 
will  help  determine  the  need  to  gimbal  the  focal  plane.  Given  restrictions  on  laser  power, 
number  of  pixels  on  target  needed  for  signal  processing,  pixel  resolution,  and  FOV,  the  seeker 
may  be  able  to  be  fixed  and  still  achieve  the  necessary  angular  FOV. 

Figures  8  through  1 1  display  similar  results  for  the  maneuvering  target.  The  required 
FOV  was  found  to  be  only  slightly  larger  in  magnitude  than  that  for  the  HVFT.  Again  the  results 
for  the  other  update  rates  showed  similar  trends  although  the  individual  curves  could  be  seen  to 
spread  out  more  at  lower  update  rates.  This  time,  however,  there  is  a  definite  knee  in  the  curve 
in  Figure  12.  The  update  rate  necessary  to  achieve  an  acceptable  miss  distance  was  determined 
to  be  10-20  Hz.  It  is  important  to  note  that  the  guidance  system  used  was  generic  and  not 
specifically  tuned  for  this  vehicle.  A  decrease  in  overall  CEP  magnitude  would  likely  occur 
when  a  guidance,  navigation,  and  control  system  designed  specifically  for  the  SSB  was 
developed.  This  would  reduce  the  CEP  to  levels  needed  to  perform  the  direct  attack  scenario 
against  all  targets.  It  is  likely,  however,  that  the  trends  for  CEP  versus  update  rate  would  be  the 
same,  and  10-20  Hz  would  still  be  needed  to  achieve  a  successful  hit. 


Conclusion 

The  MSTARS  methodology  allowed  the  rapid  development  of  a  flash  LADAR/SSB 
simulation  to  determine  preliminary  performance  requirements.  The  resulting  update  rate  and 
FOV  requirements  for  the  maneuvering  target  scenario  may  be  difficult  to  obtain  with  current 
scanning  LADAR  seekers.  This  alone  shows  the  need  to  further  investigate  flash  LADAR 
technology  that  may  be  capable  of  higher  update  rates  than  a  scanning  LADAR.  The  FOV 
requirements  were  also  valuable  in  determining  the  number  of  pixels,  pixel  resolution,  and  laser 
power  that  will  be  needed  to  perform  these  missions.  If  the  FOV  requirements  can  be  met 
without  a  gimbal  on  the  focal  plane,  the  seeker  cost  will  be  lower.  This  would  make  the  flash 
LADAR  seeker  attractive  to  advanced,  low-cost  munition  concepts. 

This  type  of  analysis  is  typical  of  what  should  be  performed  before  beginning  any  type  of 
hardware  acquisition  program.  The  results  helped  to  confirm  the  feasibility  of  the  flash  LADAR 
concept  and  will  provide  program  advocacy  information,  which  can  be  used  to  help  secure 
necessary  funding. 
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Figure  3.  Unjammed  azimuth  and  elevation  FOV  vs  time 
since  seeker  turn-on  -  100  Hz 
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Figure  4.  Jammed  azimuth  and  elevation  FOV  vs  time 
since  seeker  turn-on  -  100  Hz 
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Figure  7.  HVFT  CEP  versus  seeker  update  rate 
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Figure  8.  Unjammed  azimuth  and  elevation  FOV  vs  time 
since  seeker  turn-on  -  100  Hz  -  maneuvering  target 


Time  Since  Seeker  Turn  On  (sec) 


Figure  9.  Jammed  azimuth  and  elevation  FOV  vs  time 
since  seeker  turn-on  -  100  Hz  -  maneuvering  target 
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Figure  10.  Unjammed  azimuth  and  elevation  FOV  vs  time 
since  seeker  turn-on  -  20  Hz  -  maneuvering  target 
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Figure  11.  Jammed  azimuth  and  elevation  FOV  vs  time 
since  seeker  turn-on  -  20  Hz  -  maneuvering  target 
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Introduction 


•  Need  for  “smart”  munitions  to  minimize  collateral  damage  and  increase 
number  of  kills  per  sortie 

-  Prompted  Air  Force  to  investigate  autonomous  on-board  terminal 
seekers 

•  One  candidate  is  staring  focal  plane  LADAR  ("flash”  LADAR) 

•  Before  beginning  acquisition  program  It  was  desired  to  understand 
requirements  and  performance  Issues 

-  In-house  6-DOF  simulation  and  analysis 

•  Used  modular  simulation  tools  and  resources  (MSTARS) 
simulation  environment 

•  Visual  simulation  tool  •  VisSim 

•  Munition  components  developed  and  maintained  in  modular 
architecture 

•  Allowed  rapid  development  of  flash  LADAR/munition  simulation  in 
only  4  days 
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SSB  Size  Comparison 
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SSB  Properties 


•  250  lb  class  munition 

•  Guidance  system 

-  Terminal  flash  LADAR  Seeker  (run  at  update  rates  of  1-look  to  100  Hz) 

•  Measured  azimuth,  elevation,  range,  and  range-rate 

-  Extended  Kalmln  Filter 

•  9  state  -  position,  velocity,  and  acceleration 

•  Only  used  for  maneuvering  case 

-  Guidance  Law 

•  Maneuvering  target:  optimal  to  provide  desired  impact  angle  and 
maximum  impact  velocity 

•  Fixed  target:  proportional  navigation  (PRO-NAV) 

-  3-fin  control  system 
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Why  was  the  analysis  done? 


•  Help  the  Air  Force  understand  the  Issues  associated  with  flash  LADAR  on  direct 
attack  munitions 

-  Investigate  effect  of  seeker  update  rate  on  munition  performance 

-  Determine  preliminary  field-of-view  (FOV)  requirements  for  direct  attack  munition 

•  Fixed  target 

•  Mobile  target  performing  deceleration  maneuver 

»  Slam  on  brakes  at  seeker  acquisition 

•  Used  noisy  6-OOF  simulation  of  small  smart  bomb  (SSB)  vehicle 

-  Noisy  Seeker  measurements 

-  Noisy  INS 

-  GPS  navigation  errors 

•  Unjammed 

•  Jammed  since  launch  (-75  sec) 

-  Target  Location  Error  (TLE) 
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Monte  Carlo  Assumptions 


•  Monte  Carlo  Analysis 

-  Assumptions 

•  Acquisition  Range: 

1500  meters 

•  Launch  altitude : 

40,000  feet 

*  •  Launch  velocity : 

Mach  0.8 

•  Desired  Imp  Angle : 

85  deg 

•  Blind  Range: 

200  meters 

•  GPS  Nav  Error: 

Unjammed/Jammed 

*  TLE  Error: 

Typical 

•  Seeker  Errors: 

-  Range: 

0.5  meters 

-  Range  Rate; 

0.05  meters/sec 

-  Angular: 

0.00067  rad  =  1.0  meter  at  1500  meter  acq  range 

-  Each  set  of  runs  included  1  target  downrange  position 

•  20  km 

•  No  nominal  cross  range  location 
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MSTARS  -  Visual  Simulation  Development 
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Mobile  Target  Scenario  Flyout 
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Example  Target  Laydowns 
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Abstract 

The  information  revolution  has  created  the  ability  for  creating  powerful  tools  to  support  the  warfighter.  Tools  for 
collecting,  analyzing,  and  communicating  information  are  being  created  to  improve  the  efficiency  and  efficacy  of 
conducting  military  operations.  Unfortunately,  the  same  information  revolution  has  introduced  new  vulnerabilities 
whereby  adversaries  can  acquire,  exploit,  deny,  or  destroy  information  needed  to  support  mission  objectives. 
Information  warfare  has  emerged  to  provide  a  new  wave  of  warfare  in  which  the  focus  has  shifted  from  massive 
destruction  of  enemy  physical  assets  to  surgical  attack  on  information  assets.  In  this  paper,  we  present  a  framework 
for  supporting  information  warfare  and  information  operations  using  advanced  techniques  from  artificial  intelligence 
and  control  theory.  Specifically,  we  discuss  the  combination  of  techniques  from  approximate  reasoning,  dynamic 
programming,  and  game  theory  to  define  a  capability  to  support  the  conduct  of  information  operations. 

Introduction 

Information  systems  have  become  an  essential  element  of  military,  government,  commercial,  and  academic 
operation.  The  proliferation  of  computers,  networks,  and  related  technologies  has  provided  the  capability  to  rapidly 
collect,  store,  analyze,  and  disseminate  information  for  a  variety  of  purposes.  The  expediency,  efficiency, 
productivity,  and  profitability  of  organizations  and  individuals  have  been  significantly  enhanced  by  this  information 
revolution.  The  military  especially  benefits  from  this  progress  by  providing  decision  makers  unprecedented  quantity, 
quality,  and  timeliness  of  information.  The  commander  with  the  ability  to  know  the  order  of  battle,  analyze  events, 
and  distribute  critical  information  possesses  a  powerful  advantage. 

The  benefits  afforded  by  the  information  revolution  are  balanced  by  some  problems.  Information  is  a  potent  weapon 
and  a  lucrative  target.  The  environment  in  which  information  is  disseminated  and  stored  provides  a  means  for 
unauthorized  access  and  manipulation.  Nations,  groups,  and  individuals  seek  to  acquire,  exploit,  and  protect 
information  in  support  of  their  objectives.  This  exploitation  and  protection  of  information  can  occur  for  economic 
and  political  reasons  as  well  as  for  military  advantage.  Strategies,  both  offensive  and  defensive,  are  being  formulated 
to  address  actions  involving  the  denial,  exploitation,  corruption,  and  destruction  of  enemy  information.  These 
strategies  form  the  core  of  Information  Operations  (10)  and  Information  Warfare  (IW). 

In  this  paper,  we  discuss  a  framework  for  supporting  a  C3/C4  analyst  in  information  operations.  To  understand 
where  such  a  capability  will  benefit  the  analyst,  we  review  the  concept  of  the  command  and  control  decision  and 
execution  cycle,  also  known  as  the  “OODA  Loop.”  The  OODA  loop  consists  of  four  distinct  phases  corresponding, 
respectively,  to  observe,  orient,  decide,  and  act. 

The  first  phase  of  the  OODA  loop  is  the  observation  phase.  At  this  point,  the  analyst  or  command  collects 
information  about  the  battlespace  (i.e.,  environment)  within  which  information  operations  will  occur.  Typically, 
observation  is  constrained  to  data  collection  from  sensors  and  any  processing  necessary  to  support  the  assessment  of 
the  information  in  the  next  phase.  The  second  phase  is  orientation.  In  this  phase,  the  analyst  or  commander  interprets 
the  information  for  situation  assessment.  At  this  point,  inferences  are  drawn  from  the  information  that  has  been 
inferred  to  predict  additional  attributes  about  the  situation  (e.g.,  risk  and  strategy).  In  the  third  phase,  decision,  the 
commander  evaluates  the  results  of  situation  assessment  and  decides  on  an  appropriate  course  of  action.  The 
resulting  orders  are  passed  to  those  who  will  execute  the  orders  in  the  fourth  phase,  action. 
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Figure  1.  Interacting  Decision  and  Execution  Cycles. 


Tools  supporting  the  10  process  must  work  within  the  decision  and  execution  cycle,  as  shown  in  the  OODA  Loop. 
Specifically,  through  the  intelligence  process,  data  and  information  are  collected  about  the  target  system  and  the 
processes  that  use  that  system.  The  intelligence  process  is  responsible  for  collecting  information  both  in  support  of 
planning  and  real-time  execution.  Therefore,  the  information  to  be  observed  must  be  stored  in  a  database  or  made 
available  as  collected.  Next,  tools  need  to  be  able  to  query  relevant  information  related  to  the  current  state  and  infer 
situation  attributes  as  describe  above.  Several  techniques  exist  for  performing  such  inference,  and  we  will  suggest  a 
particular  approach  later  in  this  paper.  Given  the  inferred  situation,  tools  must  be  capable  of  assessing  the  available 
options  in  the  light  of  the  intended  goal,  the  confidence  in  the  current  view  of  the  environment,  and  the  expected 
utility  of  executing  any  of  the  options.  Finally,  resulting  actions  must  be  reflected  in  the  view  of  the  environment, 
either  through  prediction  of  impact  or  through  the  collection  of  additional  information  (or  both). 

To  ensure  accurate  representation  and  analysis  of  opponent  capabilities  in  supporting  the  10  decision  process,  the 
opponent’s  corresponding  decision  process  should  be  included.  This  can  be  represented  as  an  interaction  of  two 
OODA  loops  (Figure  1).  Since  both  cycles  affect  the  environment,  the  friendly  decision  process  should  take  into 
account  the  enemy’s  decision  cycle  to  predict  expected  outcome.  This  results  in  the  interacting  decision  cycles  being 
represented  as  a  “game,”  and  techniques  from  game  analysis  need  to  be  incorporated  into  the  decision  aid. 

In  a  game,  three  major  processes  take  place  that  coincide  with  the  OOD  phases  of  the  OODA  Loop  (Figure  2).  First, 
data  and  information  are  collected  from  the  environment  about  the  target  or  opponent.  This  information  is  used  to 
capture  a  current  “state”  of  the  game  and  is  combined  with  previously  collected  data  and  information  to  characterize 
the  entire  environment.  Such  characterization  may  consist  of  drawing  inferences  from  known  information  to 
estimate  or  predict  unknown  attributes  of  the  environment.  The  combination  of  known  and  inferred  information 
defines  the  current  “belief  state”  of  the  game.  The  belief  state  is  used,  in  combination  with  a  specific  objective,  to 
select  a  course  of  action  for  achieving  the  objective.  Once  the  action  is  taken,  the  state  of  the  environment  changes, 
and  the  process  repeats. 

A  Control-Theory  View  of  Information  Operations 


In  general,  information  operations  (and  the  OODA  loop)  can  be  viewed  as  a  special  form  of  feedback  (or  closed 
loop)  control  where  desired  environment  states  are  obtained  by  modifying  control  variables  given  the  current  state 
(Atekson,  et  al.,  1997).  Typically,  control  systems  are  modeled  in  one  of  two  ways — through  forward  models  or 
through  inverse  models.  A  forward  model  uses  the  current  state  and  the  actions  that  can  be  applied  in  that  state  to 
predict  the  results  of  the  actions  (i.e.,  the  next  state).  Typically,  this  is  represented  as  s(t+ 1 )  =J{s(t),a).  An  inverse 
model,  on  the  other  hand,  provides  an  action  given  the  current  state  and  the  desired  “outcome,”  which  may  be  the 
next  state.  Thus,  the  inverse  model  can  be  represented  as  a  =  f[s(t),s(t+\)). 


Figure  2.  Intelligent  10  Process  Flow 


Alternatively,  rather  than  using  the  next  state  as  an  explicit  parameter  in  the  model,  an  expected  payoff,  p,  (e.g., 
probability  of  kill)  can  be  used  in  the  models.  Then  the  forward  model  becomes  p  =  fis{t),a)  and  the  inverse  model 
becomes  a  =  J[s(t),p).  Using  this  alternative  form,  the  feedback  control  problem  can  be  posed  as  the  problem  of 
optimizing  the  expected  payoff  for  the  controller. 

The  controller  contains  a  “model”  of  the  process  being  controlled.  This  may  be  an  explicit  model  (e.g.,  a  set  of 
differential  equations)  or  an  implicit  model  (e.g.,  a  neural  network  or  lookup  table  matching  states  to  actions).  In  the 
context  of  intelligent  control,  it  is  expected  that  the  controller  will  process  and  modify  an  implicit  model  since  such 
a  model  is  both  computationally  efficient  and  relatively  easy  to  modify  based  on  past  experience. 

Once  the  controller  determines  the  proper  action  to  take  (based  on  a  control  policy  that  is  either  stored  or  computed), 
the  action  is  translated  into  appropriate  commands  or  signals  for  actions  to  be  taken  in  the  environment.  In  the 
following  sections,  we  will  discuss  one  possible  framework  for  implementing  this  architecture. 

Markov  Decision  Processes 

The  most  common  form  of  representation  for  the  types  of  decision  problems  outlined  above  is  the  Markov  decision 
process  (Barto,  et  al.,  1995).  A  Markov  decision  process  (MDP)  is  defined  by  a  set  of  states,  S,  a  set  of  actions,  A,  a 
set  of  transitions  between  states,  T,  associated  with  a  particular  action,  and  a  set  of  discrete  probability  distributions, 
P,  over  the  set  S.  Similarly,  T  :  S  xA  —>■  P  .  Associated  with  each  action  while  in  a  given  state  is  a  cost  (or  reward), 
c(s,a).  Given  an  MDP,  the  goal  is  to  determine  a  policy,  n(s),  (i.e.,  a  set  of  actions  to  be  applied  from  a  given  state) 
to  minimize  total  expected  discounted  cost. 

Let  f"  (s,)  represent  the  total  expected  discounted  infinite  horizon  cost  under  policy  n  from  state  st.  Let  y  (0  <  y  <  1) 
be  a  discount  factor,  having  the  effect  of  controlling  the  influence  of  future  cost  on  n.  Then, 

£r'c(s(,;r(s())|s0  =st 

.f»0 


r{st)=E, 


where  £*[•]  is  the  expectation  given  policy  it.  We  can  estimate  fK(st)  for  some  =  a  as  follows: 


.TO,) «  Qf(s,a)  =  c(st,a) +rYJp(s1\  si>a)f(Sj ) 

ar,eS 


From  this,  we  are  able  to  establish  policy,  n,  based  on  the  current  estimate  (/;  namely,  select  ^(s,.)  =  a  such  that, 
Qf‘  (s,-,^(i,))  =  min2/(.v1,fl) . 


This  equation  is  in  the  form  of  the  Bellman  optimality  equation  which  can  be  solved  for  f[sj)  using  several 
techniques  such  as  dynamic  programming  (Bellman,  1957). 

With  the  combined  OODA  loop  as  depicted  in  Figure  1,  we  can  generalize  the  development  of  a  policy  within  the 
context  of  Markov  games  (Sheppard,  1997;  Sheppard,  1998).  A  Markov  game  is  an  extension  of  the  MDP  in  which 
decisions  by  multiple  players  must  be  considered,  and  these  decisions  generally  conflict.  Under  the  restriction  of 
two-person  games,  we  define  S  to  be  a  set  of  states,  At  and  A2  to  be  sets  of  actions  for  players  1  and  2  respectively, 
and  T  to  be  a  set  of  transitions  similar  to  the  MDP,  such  that  T  :  S  x  Ax  x  A2  -»  P .  Associated  with  each  player  is  a 
cost  (or  reward)  function,  Ci(s,aha2)  and  c2(s,aha2). 

In  the  context  of  10,  the  objective  is  to  find  a  policy  711(5)  that  maximizes  total  expected  discounted  reward  in  the 
presence  of  an  opposing  policy  n2(s).  Value  functions  for  each  player  analogous  to  the  MDP  case  can  be  determined. 
For  alternating  games  (which  is  unlikely),  policies  can  be  determined  for  each  player  given  their  value  functions 
using  minimax.  In  the  event  simultaneous  games  are  being  played,  mixed  strategies  may  be  required.  For  zero-sum 
games,  policies  at  individual  states  can  be  determined  using  linear  programming  (Sheppard,  1997).  For  non-zero- 
sum  games  (which  would  result  when  the  value  functions  for  the  two  players  are  not  complementary),  a  linear 
complementarity  problem  can  be  constructed  and  solved  using  various  numeric  techniques  such  as  the  Lemke- 
Howson  algorithm  (von  Stengel,  1998). 

Implicit  Models  of  MDPs  and  Markov  Games 

Given  the  large  state  space  of  the  10  scenario,  it  is  likely  that  a  traditional  approach  using  dynamic  programming  to 
solve  these  MDPs  will  be  infeasible.  As  a  result,  some  form  of  function  approximation  will  be  required  for 
generalizing  from  representative  state-action  pairs  to  the  full  range  of  state-action  possibilities.  One  of  the  more 
common  approaches  to  function  approximation  is  the  use  of  feed-forward  neural  networks. 

The  traditional  feed-forward  neural  network  calculates  the  output  of  a  given  node,  Oj  as  CL  =  ^T'1^  wjlxi ,  where  n  is 
the  number  of  inputs  to  the  current  node.  Learning  consists  of  modifying  the  weights,  wJt  in  such  a  way  to  reduce  the 
network  error  (calculated  as  E  =  j(z-O)2 ,  where  z  is  the  expected  network  output  and  O  is  the  actual  network 
output).  This  weight  update  (called  backpropagation)  is  accomplished  by  determining  the  gradient  of  the  error 
surface  and  modifying  the  weights  in  the  direction  of  the  gradient.  Specifically,  the  weight  update  rule  for 
backpropagation  can  be  represented  as  Aw^  =a(z-0)Vw0  (Rumelhart  et  ai,  1986). 

The  standard  backpropagation  algorithm,  while  performing  well  on  classification  tasks,  has  been  shown  to  have 
difficulties  solving  highly  dynamic  problems  such  as  control  problems.  In  response  to  these  difficulties,  work  in 
reinforcement  learning  and  neural  networks  resulted  in  the  development  of  a  class  of  algorithms  capable  of  solving 
specific  types  of  control  problems.  In  particular,  temporal  difference  algorithms  have  been  shown  to  solve  highly 
complex  control  problems  that  are  posed  as  MDPs. 

Rich  Sutton  developed  an  algorithm  for  training  feed-forward  neural  networks  to  solve  control  tasks  that  can  be 
modeled  as  an  MDP  (Sutton,  1988).  Sutton’s  temporal  difference  method  focuses  on  the  problem  of  predicting 
expected  discounted  payoff  from  a  given  state.  This  method  is  applied  in  “multi-step  prediction  problems”  where 


payoff  is  not  awarded  until  several  steps  after  a  prediction  for  payoff  is  made.  At  each  step,  the  controller  predicts 
what  its  future  payoff  will  be,  based  on  several  available  actions,  and  chooses  its  action  based  on  that  prediction. 
However,  the  ramifications  for  taking  the  sequence  of  actions  are  not  revealed  until  (typically)  the  end  of  the 
process. 

According  to  Sutton,  the  temporal  difference  method  is  an  extension  of  the  prototypical  supervised  learning  rule  that 
is  based  on  gradient  descent  (as  described  above).  If  we  assume  a  prediction  depends  upon  a  vector  of  modifiable 
weights  w,  and  a  vector  of  state  variables  s,  then  supervised  learning  uses  a  set  of  paired  state  vectors  and  actual 
outcomes  to  modify  the  weights  to  reduce  the  error  between  the  predictions  and  the  known  outcomes. 

The  standard,  supervised  learning  method  works  best  for  single-step  prediction  problems.  For  multi-step  prediction, 
the  vector  w  cannot  be  updated  until  the  end  of  the  sequence,  and  all  observations  and  predictions  must  be 
remembered  until  the  end  of  the  sequence.  Sutton’s  temporal  difference  method  permits  incremental  update  and  is 
based  on  the  observation  that 

m 

k=i 

where  Pt  is  the  predicted  payoff  at  time  t,  m  is  the  number  of  steps  in  the  sequence,  and  Pm+\  =  z.  In  this  case,  the 
supervised  learning  rule  becomes 

KM/jt=a{PM-Pt)^yjPk. 

k= 1 

This  update  can  be  computed  incrementally  because  it  depends  only  on  a  pair  of  successive  predictions  (P,  and  P,+1) 
and  on  the  sum  of  past  values  for  VlvP,. 

Sutton  goes  on  to  describe  a  family  of  temporal  difference  methods  based  on  the  influence  past  updates  have  on  the 
current  update  of  the  weight  vector.  These  methods  are  based  on  a  parameter,  X  e  [0,1],  which  specifies  a  discount 
factor  in  the  prediction  equation.  Sutton  refers  to  this  family  of  equations  as  the  TD(a)  family.  When  X  =  0,  past 
updates  have  no  influence  on  the  current  update.  When  X  =  1,  all  past  predictions  receive  equal  weight.  Assuming  it 
is  desirable  for  the  update  procedure  to  be  more  sensitive  to  recent  predictions  than  to  distant  predictions,  the 
changes  are  weighted  according  to  Xk.  Thus  the  update  equation  becomes 

k= 1 

Note  this  equation  (and  the  original  gradient  descent  equation)  assumes  a  single  linear  combination  of  weights.  This 
means  that  for  a  function  to  be  learned,  that  function  must  itself  be  linear  in  the  inputs  (i.e.,  underlying  concepts 
must  be  linearly  separable).  This  limitation  can  be  addressed  by  using  the  generalized  delta  rule  as  described  in 
(Rumelhart  et  al. ,  1986). 

Modeling  Belief  States  with  Bayesian  Networks 

Given  a  neural  network  for  computing  a  value  function,  we  need  a  method  of  representing  the  state  of  the  control 
problem  being  solved.  For  the  IO  problem,  we  suggest  using  a  Bayesian  network  to  capture  the  current  belief  in  the 
state  of  the  network  under  attack.  A  Bayesian  network  is  a  network  where  the  nodes  correspond  to  random  variables 
and  directed  edges  correspond  to  dependence  (i.e.,  causal)  relationships  between  the  random  variables  (Pearl,  1988). 

Within  the  context  of  IO,  a  node  in  the  network  will  correspond  to  some  attribute  of  the  environment.  Expected 
values  for  these  attributes  are  derived  from  known  attributes  of  the  environment  (obtained  through  intelligence 
sources)  and  conditional  probabilities  of  other  values  given  certain  known  values  within  the  environment.  Using 


basic  operations  from  probability  theory,  given  a  Bayesian  network  and  certain  known  data,  probabilities  can  be 
propagated  through  the  network  to  derive  expectations  for  unknown  attributes  of  the  network. 

Bayesian  networks  are  constructed  such  that  the  “roots”  of  the  network  (defined  to  be  those  nodes  that  are 
conditioned  on  no  other  random  variables)  have  “prior”  probabilities  associated  with  them.  Interior  nodes  of  the 
network  have  conditional  probability  tables  associated  with  them  indicating  the  probability  of  the  variable  taking  on 
some  value  given  a  value  of  the  ancestor  nodes.  In  addition,  the  networks  are  constructed  to  be  “acyclic”  (i.e.,  no 
path  exists  through  the  network  from  a  node  back  to  the  same  node). 

Combining  Bayesian  Networks  and  Markov  Decision  Processes 

Key  to  determining  a  policy  that  solves  a  particular  MDP  is  the  proper  representation  of  the  state  of  the  process.  The 
10  scenario  assumes  the  decision  process  corresponds  to  controlling  the  state  of  the  environment  until  it  reaches 
some  desired  state  maximizing  a  particular  objective  function.  Using  this  approach,  we  see  that  the  Bayesian 
network  captures  the  state  of  the  environment.  From  the  beginning  of  the  attack  scenario,  we  establish  a  “baseline” 
state  using  intelligence  data,  likely  environmental  conditions,  and  likely  mission  scenarios.  Key  attributes  will  be 
derived  from  the  Bayesian  network  to  form  the  actual  state  description  for  the  Markov  decision  process.  Note  that 
this  state  need  not  represent  the  state  of  the  entire  environment.  Such  a  state  representation  would  be  too  massive  to 
be  able  to  process  efficiently.  Rather,  the  state  representation  will  focus  on  the  area  of  the  environment  of  interest  to 
the  commander. 

From  the  Bayesian  network,  an  estimate  of  the  current  state  will  be  formulated.  Based  on  that  state  and  a  set  of 
objectives  to  be  achieved,  feasible  actions  will  be  considered.  The  action  selected  will  be  one  to  maximize  the  ability 
to  achieve  the  desired  objective.  Taking  this  action  will  alter  the  state  of  the  environment.  In  the  simplest  case,  the 
state  change  will  correspond  to  a  modification  of  the  beliefs  associated  with  the  random  variables  within  the 
Bayesian  net.  In  more  extreme  cases,  the  change  in  state  may  force  a  change  in  the  structure  of  the  Bayesian  net, 
thus  requiring  recomputation  of  the  beliefs.  Either  way,  the  resulting  state  is  used  to  select  the  next  action,  and  the 
process  continues  iteratively. 

Due  to  the  large  state  space  and  the  probabilistic  view  on  whether  or  not  certain  features  hold  for  a  given  scenario, 
the  decision  problem  posed  by  information  operations  corresponds  to  a  partially  observable  MDP  (POMDP).  A 
POMDP  is  defined  by  a  set  of  states  S,  a  set  of  actions,  A,  a  set  of  transitions  between  states  associated  with  a 
particular  actions,  T,  a  set  of  probability  distributions,  P,  over  the  set  S,  a  cost  function  c(s,a),  a  set  of  observations, 
Z,  and  a  set  of  probability  distributions,  O  over  the  set  Z.  The  probability  distributions,  P,  determine  the  probability 
of  transitioning  from  state  s  to  state  s',  given  action  a.  The  probability  distributions,  O,  determine  the  probability  of 
observing  z  in  state  s'  after  taking  action  a. 

In  the  context  of  IO,  since  the  current  state  is  captured  by  value  assignments  for  known  random  variables  and 
probabilities  associated  with  possible  value  assignments  for  unknown  random  variables,  the  underlying  decision 
process  is  partially  observable.  Key  to  addressing  partial  observability  is  the  concept  of  the  belief  state  (Kaelbling, 
Littman,  &  Cassandra  1998).  A  belief  state  is  defined  to  be  a  probability  distribution  over  the  set  of  states,  S.  In  the 
case  where  the  state  estimation  is  given  by  a  Bayesian  network,  the  belief  update  process  will  correspond  to 
propagating  evidence  through  the  network  to  revise  the  specific  beliefs  of  the  random  variables. 

Given  a  representation  for  a  belief  state,  the  POMDP  can  be  cast  as  a  continuous  state-space  MDP  as  follows. 
Define  POMDP  to  have  a  set  of  belief  states,  B,  a  set  of  actions,  A  (as  before),  a  cost  function, 

%(b,  a)  =  b(s)c(s,  a) ,  and  a  set  of  transition  probabilities  defined  by 


r(b,a,b')  =  Mb’  |  a,b) 

=  ]>]Pr(h'  J  a,b,z)Mz  I  a,b) 

Z€Z 


where 


Pr (5'|M,z)=  ,;ifBN(&’3’Z)=i' 
1 0 ;  otherwise 


for  the  belief  net  represented  by  BN(Z>,  a,  z).  Since  the  belief  captures  all  information  known  about  the  state  so  far, 
even  if  the  underlying  decision  process  is  non-Markovian,  the  modified  decision  process  utilizing  these  belief  states 
is  Markovian.  Consequently,  any  technique  for  solving  continuous  state-space  MDPs  can  now  be  applied  (such  as 
the  temporal  difference  approach  described  earlier). 

At  this  point,  the  major  issue  becomes  representation  of  the  belief  state.  Specifically,  two  issues  must  be  addressed: 
the  dimensionality  of  the  state  space  and  the  continuous  nature  of  the  belief  space.  Considering  the  dimensionality 
problem,  a  naive  approach  would  involve  directly  mapping  the  random  variables  and  the  associated  probabilities  of 
their  values  to  a  belief  state  vector.  For  example,  consider  a  simple  Bayesian  network  with  five  random  variables. 
For  simplicity,  assume  each  variable  is  a  Boolean  variable  (i.e.,  either  true  or  false).  Assume  we  have  knowledge 
about  nodes  A  and  B  that  enable  us  to  derive  probabilities  for  C,  D,  and  E.  Then  the  belief  state  could  be  represented 
in  one  of  three  ways. 

1 .  {Pr(A),  Pr(B),  Pr(C),  Pr(-,C),  Pr(D),  Pr(-,D),  Pr(E),  Pr(^E)} 

2.  {arg  max{Pr(A)},  arg max{Pr(B)},  arg  max{Pr(C)},  arg  max{Pr(D)},  arg  max{Pr(E)}} 

3.  {(arg  max{Pr(A)},  Pr(A)),  (arg  max{Pr(B)},  Pr(B)),  (arg  max{Pr(C)},  Pr(C)>,  (arg  max{Pr(D)}, 
Pr(D)>,  (arg  max  {Pr(E)} ,  Pr(E)>} 

The  first  form  simply  represents  the  probabilities  of  each  of  the  values  for  each  of  the  random  variables.  The  second 
assigns  a  vector  based  on  the  Bayes  decision  criterion  (i.e,  select  the  value  with  the  maximum  probability).  The  third 
is  the  same  as  the  second  except  that  it  also  includes  the  probabilities. 

Note  that  the  first  representation  is  the  most  explicit  and,  thereby,  the  most  complex.  The  second  representation  is 
much  simpler  in  that  it  is  no  longer  infinite;  however,  a  significant  amount  of  information  is  lost  by  discarding  the 
probabilities.  The  third  representation  provides  a  compromise  between  the  first  and  second;  however,  this 
representation  does  not  simplify  the  state  space.  It  seems  clear  that  some  form  of  compaction  is  required  such  as  that 
provided  by  various  feature  selection  methods  (Wettschereck,  et  al.,  1997). 

The  second  issue  focuses  on  the  problem  of  a  continuous  state  space.  Kaelbling,  Littman,  and  Cassandra  (1998) 
address  this  issue  using  their  “witness”  algorithm  to  construct  policy  trees  based  on  dominance  properties  of  the 
underlying  policies.  Unfortunately,  even  with  clever  approaches  to  pruning  the  space  of  policy  trees,  the  approach 
still  requires  time  exponential  in  the  size  of  the  observation  space.  Another  approach  involves  constructing  a 
Bayesian  network  between  belief  states  and  representing  the  conditional  probability  tables  and  reward  functions 
using  decision  trees  (Boutilier  and  Poole  1996).  Value  iteration  is  then  applied  to  the  decision  trees  to  learn  the 
optimal  value  functions  and  is,  again,  computationally  intractable. 

The  reason  for  the  computational  complexity  is  that  both  of  these  approaches  focus  on  computing  an  exact  solution 
to  the  POMDP.  Substantial  savings  can  occur,  however,  when  settling  for  an  approximate  solution.  As  already 
discussed,  one  of  the  most  successful  approximate  solution  methods  for  MDPs  in  high-dimensional  state  spaces  is 
the  temporal  difference  neural  network,  which  has  been  used  in  very  large  state  spaces  to  leam  strong,  near-optimal 
policies  (Tesauro  1992). 

Generality  of  the  Framework 

Learning  approaches  such  as  those  described  in  the  reinforcement  learning  community  are  called  “model-free” 
because  they  require  no  specific  model  of  the  underlying  Markov  decision  process.  In  some  ways,  this  leads  to 
added  complexity  in  that  the  model  must  be  learned  from  experience.  On  the  other  hand,  this  assumption  provides 
tremendous  power  in  the  ability  to  adapt  the  process  if  environmental  elements,  sensors,  or  attack  tactics  change. 
Specifically,  the  details  of  the  control  elements  are  abstracted  out  of  the  control  model;  therefore,  it  is  a  simple 
matter  to  replace  the  controller  with  a  new  controller  should  the  problem  change.  A  neural  network  can  be 
represented  entirely  by  data  (as  a  set  of  matrices  of  weights).  Thus  no  software  modification  would  be  required 
except  in  mapping  inputs  and  outputs  to  the  appropriate  nodes  in  the  network. 


Suppose  the  environment  changes  but  the  inputs  and  outputs  remain  the  same.  The  only  difference  to  die  controller 
will  be  the  feedback  signal  (i.e.,  the  payoff)  from  the  environment.  Presumably,  the  new  environment  will  not  yield 
significantly  different  signals  unless  there  is  either  a  radical  change  in  the  task  to  be  performed.  In  any  event,  the 
temporal  difference  method  will  accept  the  new  feedback  signal  and  begin  to  modify  its  model  of  the  environment 
immediately. 

Adaptation  becomes  more  complicated  if  the  inputs  or  the  outputs  change.  Since  the  impact  is  similar,  we  will  treat 
both  of  these  situations  together.  When  using  a  neural  network,  both  the  input  data  and  the  control  data  being 
recommended  are  represented  by  numerical  input/output  in  the  network.  Changes  mean  that  the  inputs/outputs  must 
be  modified  either  through  inserting  a  new  node,  deleting  an  existing  node,  or  changing  a  node.  Note  that  changing  a 
node  is  analogous  to  a  deletion  followed  by  an  insertion.  If  a  change  is  of  a  similar  type,  it  might  make  sense  to  use 
the  original  weights  as  a  starting  point;  otherwise,  the  weights  can  be  reinitialized  for  the  new  node.  In  all  cases,  it  is 
prudent  to  retrain  the  network  in  the  simulated  environment  before  hosting  in  the  controller.  The  advantage  to  this 
iterative  approach  is  that  it  can  bootstrap  off  of  previously  learned  information. 

Conclusion 

Overall,  the  framework  described  in  this  paper  is  very  flexible  and  powerful.  It  is  flexible  in  its  ability  to  abstract 
needed  information  from  the  environment  and  in  its  ability  to  be  encapsulated  from  the  environment.  It  is  powerful 
in  that  it  supports  a  wide  variety  of  capabilities  including  feature  extraction,  function  approximation,  and  adaptive 
control.  The  algorithms  discussed  in  this  paper  are  not  the  only  ones  possible  and  are  offered  as  representative 
examples  rather  than  design  decisions.  In  the  end,  however,  it  is  felt  that  adaptive  approaches  such  as  those  offered 
above  will  offer  superior  power  and  flexibility  over  scripting  or  static  rule-based  reasoning. 
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Abstract 

The  information  revolution  has  created  the  ability  for  creating  powerful  tools  to  support  the  warfighter.  Tools  for 
collecting,  analyzing,  and  communicating  information  are  being  created  to  improve  the  efficiency  and  efficacy  of 
conducting  military  operations.  Unfortunately,  the  same  information  revolution  has  introduced  new  vulnerabilities 
whereby  adversaries  can  acquire,  exploit,  deny,  or  destroy  information  needed  to  support  mission  objectives. 
Information  warfare  has  emerged  to  provide  a  new  wave  of  warfare  in  which  the  focus  has  shifted  from  massive 
destruction  of  enemy  physical  assets  to  surgical  attack  on  information  assets.  In  this  paper,  we  present  a  framework 
for  supporting  information  warfare  and  information  operations  using  advanced  techniques  from  artificial  intelligence 
and  control  theory.  Specifically,  we  discuss  the  combination  of  techniques  from  approximate  reasoning,  dynamic 
programming,  and  game  theory  to  define  a  capability  to  support  the  conduct  of  information  operations. 

Introduction 

Information  systems  have  become  an  essential  element  of  military,  government,  commercial,  and  academic 
operation.  The  proliferation  of  computers,  networks,  and  related  technologies  has  provided  the  capability  to  rapidly 
collect,  store,  analyze,  and  disseminate  information  for  a  variety  of  purposes.  The  expediency,  efficiency, 
productivity,  and  profitability  of  organizations  and  individuals  have  been  significantly  enhanced  by  this  information 
revolution.  The  military  especially  benefits  from  this  progress  by  providing  decision  makers  unprecedented  quantity, 
quality,  and  timeliness  of  information.  The  commander  with  the  ability  to  know  the  order  of  battle,  analyze  events, 
and  distribute  critical  information  possesses  a  powerful  advantage. 

The  benefits  afforded  by  the  information  revolution  are  balanced  by  some  problems.  Information  is  a  potent  weapon 
and  a  lucrative  target.  The  environment  in  which  information  is  disseminated  and  stored  provides  a  means  for 
unauthorized  access  and  manipulation.  Nations,  groups,  and  individuals  seek  to  acquire,  exploit,  and  protect 
information  in  support  of  their  objectives.  This  exploitation  and  protection  of  information  can  occur  for  economic 
and  political  reasons  as  well  as  for  military  advantage.  Strategies,  both  offensive  and  defensive,  are  being  formulated 
to  address  actions  involving  the  denial,  exploitation,  corruption,  and  destruction  of  enemy  information  These 
strategies  form  the  core  of  Information  Operations  (10)  and  Information  Warfare  (IW). 

In  this  paper,  we  discuss  a  framework  for  supporting  a  C3/C4  analyst  in  information  operations.  To  understand 
where  such  a  capability  will  benefit  the  analyst,  we  review  the  concept  of  the  command  and  control  decision  and 
execution  cycle,  also  known  as  the  “OODA  Loop.”  The  OODA  loop  consists  of  four  distinct  phases  corresponding, 
respectively,  to  observe ,  orient,  decide,  and  act. 

The  first  phase  of  the  OODA  loop  is  the  observation  phase.  At  this  point,  the  analyst  or  command  collects 
information  about  the  battlespace  (i.e.,  environment)  within  which  information  operations  will  occur.  Typically, 
observation  is  constrained  to  data  collection  from  sensors  and  any  processing  necessary  to  support  the  assessment  of 
the  information  in  the  next  phase.  The  second  phase  is  orientation.  In  this  phase,  the  analyst  or  commander  interprets 
the  information  for  situation  assessment.  At  this  point,  inferences  are  drawn  from  the  information  that  has  been 
inferred  to  predict  additional  attributes  about  the  situation  (e.g.,  risk  and  strategy).  In  the  third  phase,  decision,  the 
commander  evaluates  the  results  of  situation  assessment  and  decides  on  an  appropriate  course  of  action.  The 
resulting  orders  are  passed  to  those  who  will  execute  the  orders  in  the  fourth  phase,  action. 
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Figure  1.  Interacting  Decision  and  Execution  Cycles. 


Tools  supporting  the  IO  process  must  work  within  the  decision  and  execution  cycle,  as  shown  in  the  OODA  Loop. 
Specifically,  through  the  intelligence  process,  data  and  information  are  collected  about  the  target  system  and  the 
processes  that  use  that  system.  The  intelligence  process  is  responsible  for  collecting  information  both  in  support  of 
planning  and  real-time  execution.  Therefore,  the  information  to  be  observed  must  be  stored  in  a  database  or  made 
available  as  collected.  Next,  tools  need  to  be  able  to  query  relevant  information  related  to  the  current  state  and  infer 
situation  attributes  as  describe  above.  Several  techniques  exist  for  performing  such  inference,  and  we  will  suggest  a 
particular  approach  later  in  this  paper.  Given  the  inferred  situation,  tools  must  be  capable  of  assessing  the  available 
options  in  the  light  of  the  intended  goal,  the  confidence  in  the  current  view  of  the  environment,  and  the  expected 
utility  of  executing  any  of  the  options.  Finally,  resulting  actions  must  be  reflected  in  the  view  of  the  environment, 
either  through  prediction  of  impact  or  through  the  collection  of  additional  information  (or  both). 

To  ensure  accurate  representation  and  analysis  of  opponent  capabilities  in  supporting  the  IO  decision  process,  the 
opponent’s  corresponding  decision  process  should  be  included.  This  can  be  represented  as  an  interaction  of  two 
OODA  loops  (Figure  1).  Since  both  cycles  affect  the  environment,  the  friendly  decision  process  should  take  into 
account  the  enemy’s  decision  cycle  to  predict  expected  outcome.  This  results  in  the  interacting  decision  cycles  being 
represented  as  a  “game,”  and  techniques  from  game  analysis  need  to  be  incorporated  into  the  decision  aid. 

In  a  game,  three  major  processes  take  place  that  coincide  with  the  OOD  phases  of  the  OODA  Loop  (Figure  2).  First, 
data  and  information  are  collected  from  the  environment  about  the  target  or  opponent.  This  information  is  used  to 
capture  a  current  “state”  of  the  game  and  is  combined  with  previously  collected  data  and  information  to  characterize 
the  entire  environment.  Such  characterization  may  consist  of  drawing  inferences  from  known  information  to 
estimate  or  predict  unknown  attributes  of  the  environment.  The  combination  of  known  and  inferred  information 
defines  the  current  “belief  state”  of  the  game.  The  belief  state  is  used,  in  combination  with  a  specific  objective,  to 
select  a  course  of  action  for  achieving  the  objective.  Once  the  action  is  taken,  the  state  of  the  environment  changes, 
and  the  process  repeats. 

A  Control-Theory  View  of  Information  Operations 

In  general,  information  operations  (and  the  OODA  loop)  can  be  viewed  as  a  special  form  of  feedback  (or  closed 
loop)  control  where  desired  environment  states  are  obtained  by  modifying  control  variables  given  the  current  state 
(Atekson,  et  al.,  1997).  Typically,  control  systems  are  modeled  in  one  of  two  ways — through  forward  models  or 
through  inverse  models.  A  forward  model  uses  the  current  state  and  the  actions  that  can  be  applied  in  that  state  to 
predict  the  results  of  the  actions  (i.e.,  the  next  state).  Typically,  this  is  represented  as  s(/+l)  =  f(s(t),a).  An  inverse 
model,  on  the  other  hand,  provides  an  action  given  the  current  state  and  the  desired  “outcome,”  which  may  be  the 
next  state.  Thus,  the  inverse  model  can  be  represented  as  a  1)). 
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Figure  2.  Intelligent  10  Process  Flow 


Alternatively,  rather  than  using  the  next  state  as  an  explicit  parameter  in  the  model,  an  expected  payoff,  p,  (e.g., 
probability  of  kill)  can  be  used  in  the  models.  Then  the  forward  model  becomes  p  =j{s(t),a )  and  the  inverse  model 
becomes  a  =  J[s(i),p).  Using  this  alternative  form,  the  feedback  control  problem  can  be  posed  as  the  problem  of 
optimizing  the  expected  payoff  for  the  controller. 

The  controller  contains  a  “model”  of  the  process  being  controlled.  This  may  be  an  explicit  model  (e.g.,  a  set  of 
differential  equations)  or  an  implicit  model  (e.g.,  a  neural  network  or  lookup  table  matching  states  to  actions).  In  the 
context  of  intelligent  control,  it  is  expected  that  the  controller  will  process  and  modify  an  implicit  model  since  such 
a  model  is  both  computationally  efficient  and  relatively  easy  to  modify  based  on  past  experience. 

Once  the  controller  determines  the  proper  action  to  take  (based  on  a  control  policy  that  is  either  stored  or  computed), 
the  action  is  translated  into  appropriate  commands  or  signals  for  actions  to  be  taken  in  die  environment  In  the 
following  sections,  we  will  discuss  one  possible  framework  for  implementing  this  architecture. 

Markov  Decision  Processes 

The  most  common  form  of  representation  for  the  types  of  decision  problems  outlined  above  is  the  Markov  decision 
process  (Barto,  et  al.,  1995).  A  Markov  decision  process  (MDP)  is  defmed  by  a  set  of  states,  S,  a  set  of  actions,  A,  a 
set  of  transitions  between  states,  T,  associated  with  a  particular  action,  and  a  set  of  discrete  probability  distributions, 
P,  over  the  set  S.  Similarly, T  :  SxA  — >  P  .  Associated  with  each  action  while  in  a  given  state  is  a  cost  (or  reward), 
c(s,a).  Given  an  MDP,  the  goal  is  to  determine  a  policy,  7t(s),  (i.e.,  a  set  of  actions  to  be  applied  from  a  given  state) 
to  minimize  total  expected  discounted  cost. 

Let  f  (si )  represent  the  total  expected  discounted  infinite  horizon  cost  under  policy  n  from  state  Sj.  Let  y  (0  <  y  <  1) 
be  a  discount  factor,  having  the  effect  of  controlling  the  influence  of  future  cost  on  jc.  Then, 

f*(si)  =  Ek  j^j''c(s,,>z-(s,»|so  =st 

_  t=0 


where  £„[•]  is  the  expectation  given  policy  n.  We  can  estimate  f*(s,)  for  some  7r0,)  =  a  as  follows: 


/*(«,)  *  Qf(sia)  =  c(s„a)  +  y£p(s,  |  .y;,tf)/(.s;) 

Sj€S 


From  this,  we  are  able  to  establish  policy,  n,  based  on  the  current  estimate  (/;  namely,  select  «r(sf)  =  a  such  that, 
e7,  (s,-,^(5,))  =  min Qf(st,a) . 


This  equation  is  in  the  form  of  the  Bellman  optimality  equation  which  can  be  solved  for  fisj)  using  several 
techniques  such  as  dynamic  programming  (Bellman,  1957). 

With  the  combined  OODA  loop  as  depicted  in  Figure  1,  we  can  generalize  the  development  of  a  policy  within  the 
context  of  Markov  games  (Sheppard,  1997;  Sheppard,  1998).  A  Markov  game  is  an  extension  of  the  MDP  in  which 
decisions  by  multiple  players  must  be  considered,  and  these  decisions  generally  conflict.  Under  the  restriction  of 
two-person  games,  we  define  S  to  be  a  set  of  states,  A,  and  Az  to  be  sets  of  actions  for  players  1  and  2  respectively, 
and  T  to  be  a  set  of  transitions  similar  to  the  MDP,  such  that  T  :  S  x  Al  x  A2  -»  P .  Associated  with  each  player  is  a 
cost  (or  reward)  function,  ci(s,aua2)  and  c2(s,al,a2). 

In  the  context  of  IO,  the  objective  is  to  find  a  policy  7ii(s)  that  maximizes  total  expected  discounted  reward  in  the 
presence  of  an  opposing  policy  7t2(i).  Value  functions  for  each  player  analogous  to  the  MDP  case  can  be  determined. 
For  alternating  games  (which  is  unlikely),  policies  can  be  determined  for  each  player  given  their  value  functions 
using  minimax.  In  the  event  simultaneous  games  are  being  played,  mixed  strategies  may  be  required.  For  zero-sum 
games,  policies  at  individual  states  can  be  determined  using  linear  programming  (Sheppard,  1997).  For  non-zero- 
sum  games  (which  would  result  when  the  value  functions  for  the  two  players  are  not  complementary),  a  linear 
complementarity  problem  can  be  constructed  and  solved  using  various  numeric  techniques  such  as  the  Lemke- 
Howson  algorithm  (von  Stengel,  1998). 

Implicit  Models  of  MDPs  and  Markov  Games 

Given  the  large  state  space  of  the  IO  scenario,  it  is  likely  that  a  traditional  approach  using  dynamic  programming  to 
solve  these  MDPs  will  be  infeasible.  As  a  result,  some  form  of  function  approximation  will  be  required  for 
generalizing  from  representative  state-action  pairs  to  the  full  range  of  state-action  possibilities.  One  of  the  more 
common  approaches  to  function  approximation  is  the  use  of  feed-forward  neural  networks. 

The  traditional  feed-forward  neural  network  calculates  the  output  of  a  given  node,  Oj  as  0;.  =  wye, ,  where  n  is 
the  number  of  inputs  to  the  current  node.  Learning  consists  of  modifying  the  weights,  w#  in  such  a  way  to  reduce  the 
network  error  (calculated  as  E  =  j-(z  -  O)2 ,  where  z  is  the  expected  network  output  and  O  is  the  actual  network 
output).  This  weight  update  (called  backpropagation)  is  accomplished  by  determining  the  gradient  of  the  error 
surface  and  modifying  the  weights  in  the  direction  of  the  gradient.  Specifically,  the  weight  update  rule  for 
backpropagation  can  be  represented  as  Awj7  =  a(z  -  0)V wO  (Rumelhart  et  al.,  1986). 

The  standard  backpropagation  algorithm,  while  performing  well  on  classification  tasks,  has  been  shown  to  have 
difficulties  solving  highly  dynamic  problems  such  as  control  problems.  In  response  to  these  difficulties,  work  in 
reinforcement  learning  and  neural  networks  resulted  in  the  development  of  a  class  of  algorithms  capable  of  solving 
specific  types  of  control  problems.  In  particular,  temporal  difference  algorithms  have  been  shown  to  solve  highly 
complex  control  problems  that  are  posed  as  MDPs. 

Rich  Sutton  developed  an  algorithm  for  training  feed-forward  neural  networks  to  solve  control  tasks  that  can  be 
modeled  as  an  MDP  (Sutton,  1988).  Sutton’s  temporal  difference  method  focuses  on  the  problem  of  predicting 
expected  discounted  payoff  from  a  given  state.  This  method  is  applied  in  “multi-step  prediction  problems”  where 


payoff  is  not  awarded  until  several  steps  after  a  prediction  for  payoff  is  made.  At  each  step,  the  controller  predicts 
what  its  future  payoff  will  be,  based  on  several  available  actions,  and  chooses  its  action  based  on  that  prediction. 
However,  the  ramifications  for  taking  the  sequence  of  actions  are  not  revealed  until  (typically)  the  end  of  the 
process. 

According  to  Sutton,  the  temporal  difference  method  is  an  extension  of  the  prototypical  supervised  learning  rule  that 
is  based  on  gradient  descent  (as  described  above).  If  we  assume  a  prediction  depends  upon  a  vector  of  modifiable 
weights  w,  and  a  vector  of  state  variables  s,  then  supervised  learning  uses  a  set  of  paired  state  vectors  and  actual 
outcomes  to  modify  the  weights  to  reduce  the  error  between  the  predictions  and  the  known  outcomes. 

The  standard,  supervised  learning  method  works  best  for  single-step  prediction  problems.  For  multi-step  prediction, 
the  vector  w  cannot  be  updated  until  the  end  of  the  sequence,  and  all  observations  and  predictions  must  be 
remembered  until  the  end  of  the  sequence.  Sutton’s  temporal  difference  method  permits  incremental  update  and  is 
based  on  the  observation  that 

m 

k=t 

where  P,  is  the  predicted  payoff  at  time  t,  m  is  the  number  of  steps  in  the  sequence,  and  Pm+l  =  z.  In  this  case,  the 
supervised  learning  rule  becomes 


H=a(PM-P,itvA. 

k^l 

This  update  can  be  computed  incrementally  because  it  depends  only  on  a  pair  of  successive  predictions  (P,  and  Ptl  l) 
and  on  the  sum  of  past  values  for  VwPt. 

Sutton  goes  on  to  describe  a  family  of  temporal  difference  methods  based  on  the  influence  past  updates  have  on  the 
current  update  of  the  weight  vector.  These  methods  are  based  on  a  parameter,  X  e  [0,1],  which  specifies  a  discount 
factor  in  the  prediction  equation.  Sutton  refers  to  this  family  of  equations  as  the  TD(A)  family.  When  X  =  0,  past 
updates  have  no  influence  on  the  current  update.  When  X  =  1,  all  past  predictions  receive  equal  weight.  Assuming  it 
is  desirable  for  the  update  procedure  to  be  more  sensitive  to  recent  predictions  than  to  distant  predictions,  the 
changes  are  weighted  according  to  Xk.  Thus  the  update  equation  becomes 

AWji=a(pni-pt)YrkvwPk. 

k= 1 

Note  this  equation  (and  the  original  gradient  descent  equation)  assumes  a  single  linear  combination  of  weights.  This 
means  that  for  a  function  to  be  learned,  that  function  must  itself  be  linear  in  the  inputs  (i.e.,  underlying  concepts 
must  be  linearly  separable).  This  limitation  can  be  addressed  by  using  the  generalized  delta  rule  as  described  in 
(Rumelhart  et  al.,  1986). 

Modeling  Belief  States  with  Bayesian  Networks 

Given  a  neural  network  for  computing  a  value  function,  we  need  a  method  of  representing  the  state  of  the  control 
problem  being  solved.  For  the  IO  problem,  we  suggest  using  a  Bayesian  network  to  capture  the  current  belief  in  the 
state  of  the  network  under  attack.  A  Bayesian  network  is  a  network  where  the  nodes  correspond  to  random  variables 
and  directed  edges  correspond  to  dependence  (i.e.,  causal)  relationships  between  the  random  variables  (Pearl,  1988). 

Within  the  context  of  IO,  a  node  in  the  network  will  correspond  to  some  attribute  of  the  environment.  Expected 
values  for  these  attributes  are  derived  from  known  attributes  of  the  environment  (obtained  through  intelligence 
sources)  and  conditional  probabilities  of  other  values  given  certain  known  values  within  the  environment.  Using 


basic  operations  from  probability  theory,  given  a  Bayesian  network  and  certain  known  data,  probabilities  can  be 
propagated  through  the  network  to  derive  expectations  for  unknown  attributes  of  the  network. 

Bayesian  networks  are  constructed  such  that  the  “roots”  of  the  network  (defined  to  be  those  nodes  that  are 
conditioned  on  no  other  random  variables)  have  “prior”  probabilities  associated  with  them.  Interior  nodes  of  the 
network  have  conditional  probability  tables  associated  with  them  indicating  the  probability  of  the  variable  taking  on 
some  value  given  a  value  of  the  ancestor  nodes.  In  addition,  the  networks  are  constructed  to  be  “acyclic”  (i.e,,  no 
path  exists  through  the  network  from  a  node  back  to  the  same  node). 

Combining  Bayesian  Networks  and  Markov  Decision  Processes 

Key  to  determining  a  policy  that  solves  a  particular  MDP  is  the  proper  representation  of  the  state  of  the  process.  The 
10  scenario  assumes  the  decision  process  corresponds  to  controlling  the  state  of  the  environment  until  it  reaches 
some  desired  state  maximizing  a  particular  objective  function.  Using  this  approach,  we  see  that  the  Bayesian 
network  captures  the  state  of  the  environment.  From  the  beginning  of  the  attack  scenario,  we  establish  a  “baseline” 
state  using  intelligence  data,  likely  environmental  conditions,  and  likely  mission  scenarios.  Key  attributes  will  be 
derived  from  the  Bayesian  network  to  form  the  actual  state  description  for  the  Markov  decision  process.  Note  that 
this  state  need  not  represent  the  state  of  the  entire  environment.  Such  a  state  representation  would  be  too  massive  to 
be  able  to  process  efficiently.  Rather,  the  state  representation  will  focus  on  the  area  of  the  environment  of  interest  to 
the  commander. 

From  the  Bayesian  network,  an  estimate  of  the  current  state  will  be  formulated.  Based  on  that  state  and  a  set  of 
objectives  to  be  achieved,  feasible  actions  will  be  considered.  The  action  selected  will  be  one  to  maximize  the  ability 
to  achieve  the  desired  objective.  Taking  this  action  will  alter  the  state  of  the  environment.  In  the  simplest  case,  the 
state  change  will  correspond  to  a  modification  of  the  beliefs  associated  with  the  random  variables  within  the 
Bayesian  net.  In  more  extreme  cases,  the  change  in  state  may  force  a  change  in  the  structure  of  the  Bayesian  net, 
thus  requiring  recomputation  of  the  beliefs.  Either  way,  the  resulting  state  is  used  to  select  the  next  action,  and  the 
process  continues  iteratively. 

Due  to  the  large  state  space  and  the  probabilistic  view  on  whether  or  not  certain  features  hold  for  a  given  scenario, 
the  decision  problem  posed  by  information  operations  corresponds  to  a  partially  observable  MDP  (POMDP).  A 
POMDP  is  defined  by  a  set  of  states  S,  a  set  of  actions,  A,  a  set  of  transitions  between  states  associated  with  a 
particular  actions,  T,  a  set  of  probability  distributions,  P,  over  the  set  S,  a  cost  function  c{s,a),  a  set  of  observations, 
Z,  and  a  set  of  probability  distributions,  O  over  the  set  Z.  The  probability  distributions,  P,  determine  the  probability 
of  transitioning  from  state  s  to  state  s',  given  action  a.  The  probability  distributions,  O,  determine  the  probability  of 
observing  z  in  state  s'  after  taking  action  a. 

In  the  context  of  IO,  since  the  current  state  is  captured  by  value  assignments  for  known  random  variables  and 
probabilities  associated  with  possible  value  assignments  for  unknown  random  variables,  the  underlying  decision 
process  is  partially  observable.  Key  to  addressing  partial  observability  is  the  concept  of  the  belief  state  (Kaelbling, 
Littman,  &  Cassandra  1998).  A  belief  state  is  defined  to  be  a  probability  distribution  over  the  set  of  states,  S.  In  the 
case  where  the  state  estimation  is  given  by  a  Bayesian  network,  the  belief  update  process  will  correspond  to 
propagating  evidence  through  the  network  to  revise  the  specific  beliefs  of  the  random  variables. 

Given  a  representation  for  a  belief  state,  the  POMDP  can  be  cast  as  a  continuous  state-space  MDP  as  follows. 
Define  POMDP  to  have  a  set  of  belief  states,  B,  a  set  of  actions,  A  (as  before),  a  cost  function, 

%{b,  a)  =  ^seS  b(s)c(s,  a) ,  and  a  set  of  transition  probabilities  defined  by 


r(b,a,b')  =  Pr (b'  \  a,b) 

=  ^]Pr(//  |  a,b,  z)Pr(z  |  a,b) 

zeZ 


where 


TWTnr  ,  EN(b,a,z)  =  b 

Pr  (b'\b,a,z)  =  \  ' 

|0 ;  otherwise 

* 

for  the  belief  net  represented  by  BN(b,  a,  z).  Since  the  belief  captures  all  information  known  about  the  state  so  far, 
even  if  the  underlying  decision  process  is  non-Markovian,  the  modified  decision  process  utilizing  these  belief  states 
is  Markovian.  Consequently,  any  technique  for  solving  continuous  state-space  MDPs  can  now  be  applied  (such  as 
the  temporal  difference  approach  described  earlier). 

At  this  point,  the  major  issue  becomes  representation  of  the  belief  state.  Specifically,  two  issues  must  be  addressed: 
the  dimensionality  of  the  state  space  and  the  continuous  nature  of  the  belief  space.  Considering  the  dimensionality 
problem,  a  naive  approach  would  involve  directly  mapping  the  random  variables  and  the  associated  probabilities  of 
their  values  to  a  belief  state  vector.  For  example,  consider  a  simple  Bayesian  network  with  five  random  variables. 
For  simplicity,  assume  each  variable  is  a  Boolean  variable  (i.e.,  either  true  or  false).  Assume  we  have  knowledge 
about  nodes  A  and  B  that  enable  us  to  derive  probabilities  for  C,  D,  and  E.  Then  the  belief  state  could  be  represented 
in  one  of  three  ways. 

1.  (Pr(A),  Pr(B),  Pr(C),  Pr(^C),  Pr(D),  Pr(^D),  Pr(E),  Pr(^E)} 

2.  {arg  max{Pr(A)},  arg  max{Pr(B)},  arg  max{Pr(C)},  arg  max{Pr(D)},  arg  max{Pr(E)}} 

3.  {(arg  max{Pr(A)},  Pr(A)>,  (arg  max{Pr(B)},  Pr(B)),  (arg  max{Pr(C)},  Pr(C)),  (arg  max{Pr(D)}, 
Pr(D)>,  (arg  max{Pr(E)},  Pr(E))} 

The  first  form  simply  represents  the  probabilities  of  each  of  the  values  for  each  of  the  random  variables.  The  second 
assigns  a  vector  based  on  the  Bayes  decision  criterion  (i.e,  select  the  value  with  the  maximum  probability).  The  third 
is  the  same  as  the  second  except  that  it  also  includes  the  probabilities. 

Note  that  the  first  representation  is  the  most  explicit  and,  thereby,  the  most  complex.  The  second  representation  is 
much  simpler  in  that  it  is  no  longer  infinite;  however,  a  significant  amount  of  information  is  lost  by  discarding  the 
probabilities.  The  third  representation  provides  a  compromise  between  the  first  and  second;  however,  this 
representation  does  not  simplify  the  state  space.  It  seems  clear  that  some  form  of  compaction  is  required  such  as  that 
provided  by  various  feature  selection  methods  (Wettschereck,  et  al.,  1997). 

The  second  issue  focuses  on  the  problem  of  a  continuous  state  space.  Kaelbling,  Littman,  and  Cassandra  (1998) 
address  this  issue  using  their  “witness”  algorithm  to  construct  policy  trees  based  on  dominance  properties  of  the 
underlying  policies.  Unfortunately,  even  with  clever  approaches  to  pruning  the  space  of  policy  trees,  the  approach 
still  requires  time  exponential  in  the  size  of  the  observation  space.  Another  approach  involves  constructing  a 
Bayesian  network  between  belief  states  and  representing  the  conditional  probability  tables  and  reward  functions 
using  decision  trees  (Boutilier  and  Poole  1996).  Value  iteration  is  then  applied  to  the  decision  trees  to  learn  the 
optimal  value  functions  and  is,  again,  computationally  intractable. 

The  reason  for  the  computational  complexity  is  that  both  of  these  approaches  focus  on  computing  an  exact  solution 
to  the  POMDP.  Substantial  savings  can  occur,  however,  when  settling  for  an  approximate  solution.  As  already 
discussed,  one  of  the  most  successful  approximate  solution  methods  for  MDPs  in  high-dimensional  state  spaces  is 
the  temporal  difference  neural  network,  which  has  been  used  in  very  large  state  spaces  to  learn  strong,  near-optimal 
policies  (Tesauro  1992). 

Generality  of  the  Framework 

Learning  approaches  such  as  those  described  in  the  reinforcement  learning  community  are  called  “model-free” 
because  they  require  no  specific  model  of  the  underlying  Markov  decision  process.  In  some  ways,  this  leads  to 
added  complexity  in  that  the  model  must  be  learned  from  experience.  On  the  other  hand,  this  assumption  provides 
tremendous  power  in  the  ability  to  adapt  the  process  if  environmental  elements,  sensors,  or  attack  tactics  change. 
Specifically,  the  details  of  the  control  elements  are  abstracted  out  of  the  control  model;  therefore,  it  is  a  simple 
matter  to  replace  the  controller  with  a  new  controller  should  the  problem  change.  A  neural  network  can  be 
represented  entirely  by  data  (as  a  set  of  matrices  of  weights).  Thus  no  software  modification  would  be  required 
except  in  mapping  inputs  and  outputs  to  the  appropriate  nodes  in  the  network. 


Suppose  the  environment  changes  but  the  inputs  and  outputs  remain  the  same.  The  only  difference  to  the  controller 
will  be  the  feedback  signal  (i.e.,  the  payoff)  from  the  environment.  Presumably,  the  new  environment  will  not  yield 
significantly  different  signals  unless  there  is  either  a  radical  change  in  the  task  to  be  performed.  In  any  event,  the 
temporal  difference  method  will  accept  the  new  feedback  signal  and  begin  to  modify  its  model  of  the  environment 
immediately. 

Adaptation  becomes  more  complicated  if  the  inputs  or  the  outputs  change.  Since  the  impact  is  similar,  we  will  treat 
both  of  these  situations  together.  When  using  a  neural  network,  both  the  input  data  and  the  control  data  being 
recommended  are  represented  by  numerical  input/output  in  the  network.  Changes  mean  that  the  inputs/outputs  must 
be  modified  either  through  inserting  a  new  node,  deleting  an  existing  node,  or  changing  a  node.  Note  that  changing  a 
node  is  analogous  to  a  deletion  followed  by  an  insertion.  If  a  change  is  of  a  similar  type,  it  might  make  sense  to  use 
the  original  weights  as  a  starting  point;  otherwise,  the  weights  can  be  reinitialized  for  the  new  node.  In  all  cases,  it  is 
prudent  to  retrain  the  network  in  the  simulated  environment  before  hosting  in  the  controller.  The  advantage  to  this 
iterative  approach  is  that  it  can  bootstrap  off  of  previously  learned  information. 

Conclusion 

Overall,  the  framework  described  in  this  paper  is  very  flexible  and  powerful.  It  is  flexible  in  its  ability  to  abstract 
needed  information  from  the  environment  and  in  its  ability  to  be  encapsulated  from  the  environment.  It  is  powerful 
in  that  it  supports  a  wide  variety  of  capabilities  including  feature  extraction,  function  approximation,  and  adaptive 
control.  The  algorithms  discussed  in  this  paper  are  not  the  only  ones  possible  and  are  offered  as  representative 
examples  rather  than  design  decisions.  In  the  end,  however,  it  is  felt  that  adaptive  approaches  such  as  those  offered 
above  will  offer  superior  power  and  flexibility  over  scripting  or  static  rule-based  reasoning. 
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Why  A  Prognostics  Framew 
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What  is  the  Prognostics  Framework 
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Abstract  -  In  this  paper  we  discuss  the  use  of  information  modeling  to  develop  information  exchange  standards  and  metrics 
for  test  and  diagnostics.  For  example,  fault  information  is  being  transferred  from  one  diagnostic  reasoner  to  another.  How 
many  attributes  does  a  fault  have?  One,  three,  fifteen?  How  do  these  attributes  relate  to  the  fault,  to  diagnosis,  and  tests? 
If  both  reasoners  do  not  understand  the  “model”  of  a  fault,  then  there  will  not  be  an  information  exchange.  Humans  can, 
when  they  are  aware  of  the  differences,  resolve  the  mismatch  in  information.  Computer  programs  cannot  “talk”  until  they 
resolve  small  differences  in  conceptual  information.  We  present  an  overview  of  the  current  and  future  directions  of  the 
Artificial  Intelligence  Exchange  and  Service  Tie  to  All  Test  Environments  (AI-ESTATE)  standards.  We  present  a  summary  of 
the  work  completed  so  far  on  the  diagnostic  reasoner  exchange  standard  and  on  the  testability  metrics  standard. 

We  address  objectives,  document  organization,  information  modeling,  service  versus  API  specification,  and  other  issues 
raised  by  the  AI-ESTATE  community.  We  also  discuss  the  vision  of  the  AI-ESTATE  subcommittee  in  its  work  to  integrate  the 
AI-ESTATE  information  models  and  projects  such  as  testability/diagnosability  assessment  and  test/maintenance  feedback. 

INTRODUCTION 


The  Artificial  Intelligence  Exchange  and  Service  Tie  to  All  Test  Environments  (AI-ESTATE)  standards  are 
information  exchange  standards  for  test  and  diagnosis.  The  original  standards,  the  1232  series,  developed  a 
means  of  exchange  of  information  between  diagnostic  reasoners.  As  the  information  models  for  the  1232 
standards  were  developed,  it  became  apparent  that  these  models  could  be  used  for  standardizing  testability  and 
diagnosability  metrics.  This  paper  will  be  discussing  the  test  and  diagnosis  information  exchange  standards 
followed  by  the  testability  and  diagnosability  standards.  Other  applications  of  these  models  will  be  briefly 
described. 

In  1998,  the  third  of  a  series  of  three  standards  was  published  by  the  IEEE  addressing  issues  in  system-level 
diagnostics.  IEEE  Std  1232-1995  defines  the  architecture  of  an  AI-ESTATE-conformant  system  and  has  been 
published  as  a  “full-use”  standard;  however,  this  standard  was  published  before  the  vision  of  AI-ESTATE  was 
fully  developed.  IEEE  Std  1232.1-1997  defines  a  knowledge  and  data  exchange  standard  and  was  published  as 
a  “trial-use”  standard.  Trial-use  indicates  that  it  is  preliminary  in  nature,  and  the  standards  committee  is  seeking 
comments  from  organizations  attempting  to  implement  or  use  the  standard.  In  1998,  IEEE  Std  1232.2-1998  was 
approved.  Its  publication,  also  as  a  “trial-use”  standard  is  imminent.  This  standard  formally  defines  a  set  of 
standard  software  services  to  be  provided  by  a  diagnostic  reasoner  in  an  open-architecture  test  environment. 
Since  it  is  also  a  trial-use  standard,  comment  and  feedback  are  necessary  here  as  well.  The  standards  were 
developed  using  information  modeling,  resulting  in  the  definition  of  four  information  models  addressing  static  and 
dynamic  aspects  of  the  diagnostic  domain.  Further,  the  IEEE  1232  AI-ESTATE  series  of  standards  provide  the 
foundation  for  precise  and  unambiguous  testability  and  diagnosability  metrics. 

As  systems  became  more  complex,  costly,  and  difficult  to  diagnose  and  repair,  initiatives  were  started  to  address 
these  problems.  The  objective  of  one  of  these  initiatives,  testability,  was  to  make  systems  easier  to  test.  Early 


on,  this  focused  on  having  enough  test  points  in  the  right  places.  As  systems  evolved,  it  was  recognized  that  the 
system  design  had  to  include  characteristics  to  make  the  system  easier  to  test.  This  was  the  start  of  considering 
testability  as  a  design  characteristic.  As  defined  in  MIL-STD-2165,  testability  is  “a  design  characteristic  which 
allows  the  status  (operable,  inoperable,  or  degraded)  of  an  item  to  be  determined  and  the  isolation  of  faults  within 
the  item  to  be  performed  in  a  timely  manner.”  [1],  The  purpose  of  MIL-STD-2165  was  to  provide  uniform 
procedures  and  methods  to  control  planning,  implementation,  and  verification  of  testability  during  the  system 
acquisition  process  by  the  Department  of  Defense  (DoD).  It  was  to  be  applied  during  all  phases  of  system 
development — from  concept  to  production  to  fielding.  This  standard,  though  deficient  in  some  areas,  provided 
useful  guidance  to  government  suppliers.  Further,  lacking  any  equivalent  industry  standard,  many  commercial 
system  developers  have  used  it  to  guide  their  activities  although  it  was  not  imposed  as  a  requirement. 

In  this  paper,  we  present  an  overview  of  the  current  and  future  directions  of  the  AI-ESTATE  standards.  We 
address  objectives,  document  organization,  information  modeling,  service  versus  Applications  Program  Interface 
(API)  specification,  and  other  issues  raised  by  the  AI-ESTATE  community.  We  also  discuss  the  vision  of  the  AI- 
ESTATE  subcommittee  in  its  work  to  integrate  the  AI-ESTATE  information  models  and  projects  such  as 
testability/diagnosability  assessment  and  test/  maintenance  feedback. 

A  VISION  FOR  TEST  AND  DIAGNOSIS  STANDARDS 


Diagnosis 

The  vision  of  AI-ESTATE  is  to  provide  an  integrated,  formal  view  of  diagnostic  information  as  it  exists  in 
diagnostic  knowledge  bases  and  as  it  is  used  (or  generated)  in  diagnostic  systems.  We  assert  that  the  whole 
purpose  of  testing  is  to  perform  diagnosis  [2],  In  justifying  this  assumption,  we  rely  on  a  very  general  definition  of 
diagnosis,  derived  from  its  Greek  components  (8ia  yiyvkk™®)  meaning,  “to  discern  apart.”  Given  such  a  broad 
definition,  all  testing  is  done  to  provide  information  about  the  object  being  tested  and  to  differentiate  some  state 
of  that  object  from  a  set  of  possible  states. 

In  support  of  this  vision,  the  AI-ESTATE  committee  has  been  working  on  combining  the  existing  standards  into  a 
single,  cohesive  standard.  This  “unified”  standard  provides  formal  specifications  of  all  of  the  information  models 
(both  for  file  exchange  and  for  diagnostic  processing),  from  which  the  service  specifications  are  then  derived  and 
specified.  The  architectural  framework  is  retained  at  the  conceptual  level  to  emphasize  that  a  wide  variety  of 
implementation  models  are  possible  that  still  support  standard  exchange  of  information  as  long  as  the  definition 
of  that  information  is  clear  and  unambiguous.  Thus,  in  a  sense,  the  models  define  the  architecture,  and  the 
implementation  is  left  entirely  to  the  implementer. 

With  this  vision  in  mind,  we  believe  AI-ESTATE  plays  a  central  role  in  any  test  environment  (thus  the  “All  Test 
Environments”  part  of  the  name).  To  date,  the  focus  of  the  standards  has  been  the  development  of 
specifications  supporting  diagnosis  in  the  traditional  sense  of  the  word  (i.e.,  fault  isolation).  However,  the 
broader  context  within  which  AI-ESTATE  is  envisioned  to  participate  involves  tying  diagnostic  information  to 
explicit  product  behavior  descriptions,  assessments  of  the  ability  of  testing  to  satisfy  its  requirements,  and 
maturation  of  the  diagnostic  process  through  test  and  maintenance  information  feedback. 

Testability 

In  1997,  the  AI-ESTATE  committee  began  to  work  on  a  new  standard  focusing  on  replacing  the  cancelled  MIL- 
STD  2165.  The  military  standard  focused  on  specifying  the  essential  elements  of  a  testability  program  and 
explained  the  elements  needed  to  define  a  testability  program  plan.  In  addition,  MIL-STD  2165  included  the 
“definition”  of  several  testability  metrics,  including  a  testability  checklist  to  be  used  to  determine  overall  system 
testability.  With  the  cancellation  of  military  standards  and  specifications  by  the  Perry  Memo  in  1994  [3],  and  with 
the  lack  of  specificity  and  clarity  in  MIL-STD  2165,  it  became  evident  that  a  replacement  was  necessary. 


The  approach  being  taken  to  develop  this  standard  involves  defining  testability  and  diagnosability  metrics  based 
on  standard  information  models.  Specifically,  it  was  found  that  the  AI-ESTATE  models  provided  an  excellent 
foundation  for  defining  these  metrics 

THE  AI-ESTATE  ARCHITECTURE 


According  to  IEEE  Std  1232-1995,  the  AI-ESTATE  architecture  is  “a  conceptual  model”  in  which  “AI-ESTATE 
applications  may  use  any  combination  of  components  and  intercomponent  communication”  [4],  On  the  other 
hand,  according  to  IEEE  Std  1232.2-1998,  AI-ESTATE  includes  explicit  definitions  of  services  to  be  provided  by 
a  diagnostic  reasoner,  where  the  services  “can  be  thought  of  as  responses  to  client  requests  from  the  other 
components  of  the  system  architecture”  [5].  More  specifically,  “each  of  the  elements  that  interface  with  the 
reasoner  will  interact  through  [an]  application  executive  and  will  provide  its  own  set  of  encapsulated  services  to 
its  respective  clients”  [5]. 

Although  not  necessarily  obvious  from  the  standards  themselves,  these  two  “views”  of  the  AI-ESTATE 
architecture  present  an  interesting  dichotomy.  Specifically,  the  architecture  standard  provides  a  concept  of  AI- 
ESTATE  that  permits  any  communication  mechanism  to  be  used  between  components  of  a  test  environment  in 
support  of  the  diagnostics  provided  by  that  environment.  The  service  specification,  on  the  other  hand,  seems  to 
cast  the  communication  mechanism  in  the  form  of  a  client-server  architecture. 


We  note  that  the  intent  of  AI-ESTATE  is  to  provide  a  formal,  standard  framework  for  the  exchange  of  diagnostic 
information  (both  static  and  dynamic)  in  a  test  environment.  This  exchange  occurs  at  two  levels.  At  the  first 
level,  data  and  knowledge  are  exchanged  through  a  neutral  exchange  format,  as  specified  by  IEEE  Std  1232.1- 

1997  [6].  At  the  second  level,  specified 
by  IEEE  Std  1232.2-1998  [5]information  is 
exchanged  as  needed  between  software 
applications  within  the  test  environment. 
This  information  includes  entities  from  a 
model  or  information  on  the  current  state 
of  the  diagnostic  process. 


To  facilitate  encapsulation  of  the 
information  and  the  underlying 
mechanisms  providing  that  encapsulation, 
AI-ESTATE  assumes  the  presence  of  an 
“application  executive.”  We  emphasize 
that  this  application  executive  need  not  be 
a  physically  separate  software  process  but 
can  be  identified  as  a  “view”  of  the  software  process  when  it  involves  the  communication  activity.  This  view  of 
the  architecture  is  shown  in  Figure  1.  In  the  following  sections,  we  will  provide  a  more  detailed  discussion  of  the 
exchange  and  service  elements  of  the  architecture. 


Figure  1.  AI-ESTATE  Architecture 


Data  and  Knowledge  Exchange 

ISO  10303-11  (EXPRESS)  and  ISO  10303-12  (EXPRESS-1)  are  used  to  define  information  models  and 
exchange  formats  for  diagnostic  knowledge  [7],  [8].  These  international  standards  are  being  maintained  by  the 
STEP  (Standard  for  the  Exchange  of  Product  model  data)  community.  The  current  approach  to  static 
information  exchange  within  AI-ESTATE  is  to  derive  the  exchange  format  from  the  formal  information  models  as 
specified  in  the  ISO  standards. 

The  purpose  of  information  modeling  is  to  provide  a  formal  specification  of  the  semantics  of  information  that  is 
being  used  in  an  “information  system.”  Specifically,  information  models  identify  the  key  entities  of  information  to 
be  used,  their  relationships  to  one  another,  and  the  “behavior”  of  these  entities  in  terms  of  constraints  on  valid 
values  [9].  The  intent  is  to  ensure  that  definitions  of  these  entities  are  unambiguous. 


For  example,  central  to  the  test  and  diagnosis  problem  is  the  definition  of  a  “test.”  If  we  ask  a  digital  test 
engineer  what  a  test  is,  it  is  possible  that  the  answer  will  be  something  like  “a  set  of  vectors  used  to  determine 
whether  or  not  a  digital  circuit  is  working  properly.”  On  the  other  hand,  if  we  ask  a  diagnostic  modeler  what  a  test 
is,  the  answer  is  likely  to  be  “any  combination  of  stimulus,  response,  and  a  basis  for  comparison  that  can  be  used 
to  detect  a  fault.” 

On  the  surface,  these  two  definitions  appear  very  similar;  however,  there  is  a  fundamental  difference.  For  the 
digital  test  engineer,  there  is  an  implicit  assumption  that  a  “test”  corresponds  to  the  entire  suite  of  vectors.  For 
the  diagnostic  modeler,  individual  vectors  are  tests  as  well. 

As  a  similar  example,  the  test  engineer  and  diagnostic  modeler  are  likely  to  have  different  definitions  for 
“diagnosis.”  The  act  of  doing  diagnosis,  for  most  test  engineers,  corresponds  to  running  tests  after  dropping  off 
of  the  “go-path.”  For  the  diagnostic  modeler,  since  “no  fault”  is  a  diagnosis,  the  entire  test  process  (including  the 
go-path)  is  part  of  doing  diagnosis. 

It  may  appear  that  we  are  “splitting  hairs,”  but  formal  definition  of  terms  and  information  entities  is  an  exercise  in 
splitting  hairs.  Further,  such  hair-splitting  is  essential  to  ensure  that  communication  is  unambiguous — especially 
when  we  are  concerned  with  communication  between  software  processes.  No  assumption  can  go  unstated; 


Figure  2.  Revised  Common  Element  Model 


otherwise,  the  risk  exists  that  something  will  be  misunderstood.  Information  models  formally  state  all  of  the 
assumptions. 


A  New  Information  Model 

When  IEEE  1232.1  was  published,  it  was  published  as  a  “trial-use”  standard  to  provide  a  period  for  people  to 
study  it,  attempt  to  implement  it,  and  provide  feedback  to  the  AI-ESTATE  committee  on  the  ability  of  the 
standard  to  satisfy  the  stated  requirements.  Since  publication,  comments  have  been  received  to  indicate  that 
ambiguity  still  exists  in  the  information  models. 

Because  of  the  concern  that  the  information  models  are  still  ambiguous,  the  models  are  undergoing  close 
examination  and  modification.  It  is  interesting  to  note  that  much  of  the  ambiguity  has  been  identified  in 
connection  with  a  related  standard  being  developed  by  the  AI-ESTATE  committee — PI  522  Standard  for 
Testability  and  Diagnosability  Metrics  and  Characteristics.  AI-ESTATE’s  approach  to  developing  this  new 
standard  involved  defining  the  metrics  based  on  the  information  models  within  the  PI  232  standard.  As  we  were 
identifying  metrics  to  be  standardized,  we  discovered  that  the  current  models  were  incapable  of  supporting  their 
definition. 

A  conceptual  view  of  the  revised  common  element  model  is  shown  in  Figure  2.  Of  note  in  the  revised  model  is 
the  addition  of  a  context  entity  and  the  differentiation  between  fault  and  function.  Many  diagnostic  tools  are 
highly  context  dependent  (e.g.,  different  procedures  are  suggested  based  on  the  environmental  conditions  of  the 
test  or  the  skill  levels  of  the  maintenance  technicians).  In  addition,  several  tools  focus  on  modeling  function 
rather  than  physical  faults  to  support  modeling  at  the  system  level.  Since  the  distinctions  among  context  and 
type  of  analysis  were  not  previously  made  explicit,  new  entities  were  defined  to  eliminate  ambiguity  that  may 
arise  from  different  approaches  and  contexts  for  modeling. 

Diagnostic  Services 

The  approach  taken  to  defining  services  in  AI-ESTATE  has  been  based  on  the  traversal  (i.e.,  the  following  of  the 
relationships  defined  between  model  entities  to  access  specific  pieces  of  information  in  the  models)  of  the 
information  models.  The  “simplest”  services  involve  traversing  the  models  defined  in  IEEE  1232.1  (i.e.,  the 
exchange  models);  however,  these  models  provide  little  functionality  in  terms  of  actual  diagnosis. 

In  IEEE  1232.2,  a  novel  use  of  information  modeling  was  applied  in  that  a  dynamic  information  model  was 
specified  to  support  dynamic  services.  This  model,  called  the  “dynamic  context  model,”  relied  on  dynamically 
creating  entities  that  populate  the  model  during  a  diagnostic  session.  In  fact,  as  suggested  by  “dcm. session”  and 
“dcm.step”  in  the  model  shown  in  Figure  2,  a  diagnostic  session  is  modeled  as  a  sequence  of  steps  instantiated 
from  the  set  of  possible  values  specified  in  the  static  model.  Details  of  how  the  service  specification  is  expected 
to  be  implemented  can  be  found  in  [1 0],  [11]. 

One  of  the  concerns  raised  by  a  member  of  the  AI-ESTATE  committee  was  whether  the  standard  specifies  a  set 
of  services  or  simply  an  Application  Programming  Interface.  The  claim  was  that  the  service  specification  must 
include  a  behavior  specification  as  well  and  that  this  can  only  be  accomplished  by  defining  a  set  of  baseline 
behaviors,  perhaps  through  some  sort  of  test  bed. 

The  committee  observed  that  people  have  different  opinions  over  the  difference  between  a  service  specification 
and  an  API  specification.  Many,  in  fact,  took  issue  with  the  claim  that  they  were  different.  Further,  it  was 
determined  that  including  test  cases  to  specify  standard  behavior  was  not  desirable  in  this  context  due  to  the 
wide  variety  of  diagnostic  approaches  using  common  diagnostic  knowledge.  Rather,  it  was  believed  that  it  was 
more  important  for  the  information  itself  to  be  standardized  and  the  specific  behavior  to  be  left  to  the 
implementation. 


Testability  and  Diagnosability  Metrics 


Testability  has  been  broadly  recognized  as  the  “-ility”  that  deals  with  those  aspects  of  a  system  that  allow  the 
status  (operable,  inoperable,  or  degraded)  or  health  state  to  be  determined.  Early  work  in  the  field  primarily  dealt 
with  the  design  aspects  such  as  controllability  and  observability.  Almost  from  the  start  this  was  applied  to  the 
manufacturing  of  systems  where  test  was  seen  as  a  device  to  improve  production  yields.  This  has  been  slowly 
expanded  to  include  the  aspects  of  field  maintainability  such  as  false  alarms,  isolation  percentages,  and  other 
factors  associated  with  the  burden  of  maintaining  a  system. 

In  the  industry,  many  terms  such  as  test  coverage  and  Fraction  of  Fault  Detection  (FFD)  are  not  precisely 
defined  or  have  multiple  definitions.  Further,  each  diagnostic  tool  calculates  these  terms  differently  and 
therefore  the  results  are  not  directly  comparable.  Some  measures,  such  as  false  alarm  rate,  are  not  measurable 
in  field  applications.  Other  measures  such  as  Incremental  Fault  Resolution,  Operational  Isolation,  and  Fault 
Isolation  Resolution  appear  different,  but  mean  nearly  the  same  thing. 

Lacking  well-defined  testability  measures,  the  tasks  of  establishing  testability  requirements,  and  predicting  and 
evaluating  the  testability  of  the  design  are  extremely  difficult.  This  in  turn  makes  effective  participation  in  the 
design  for  testability  process  difficult.  These  difficulties  will  be  greatly  diminished  by  the  establishment  of 
standard  testability  metrics.  An  immediate  benefit  will  come  with  a  consistent,  precise,  and  measurable  set  of 
testability  attributes  that  can  be  compared  across  systems,  tools,  and  within  iterations  of  a  system’s  design. 

MIL-STD-2165  did  not  have  precise  and  unambiguous  definitions  of  measurable  testability  figures-of-merit  and 
relied  mostly  on  a  weighting  scheme  for  testability  assessment.  (It  should  be  noted,  however,  that  the  standard 
did  permit  the  use  of  analytical  tools  for  testability  assessment  such  as  SCOAP,  STAMP,  and  WSTA). 

As  we  strive  to  establish  concurrent  engineering  practices,  the  interchange  between  the  testability  function  and 
other  functions  becomes  even  more  important.  To  create  integrated  diagnostic  environments,  where  the 
elements  of  automatic  testing,  manual  testing,  training,  maintenance  aids,  and  technical  information  work  in 
concert  with  the  testability  element,  we  must  maximize  the  reuse  of  data,  information,  knowledge,  and  software. 
Complete  diagnostic  systems  include  Built-In-Test  (BIT),  Automatic  Test  Equipment  (ATE),  and  manual 
troubleshooting.  It  would  be  desirable  to  be  able  to  predict  and  evaluate  the  testability  of  systems  at  these 
levels. 

It  is  not  an  accident  that  the  PI  522  standard  contains  both  the  word  testability  and  the  word  diagnosability.  The 
distinction  is  not  always  easy  to  maintain,  especially  in  light  of  the  expansion  of  the  use  of  the  testability  term. 
Figure  3  shows  the  basic  relationship,  with  diagnosability  being  the  larger  term  and  encompassing  all  aspects  of 
detection,  fault  localization,  and  fault  identification.  The  boundary  is  fuzzy  and  often  it  is  not  clear  when  one  term 
applies  and  the  other  does  not.  The  PI  522  standard  is  meant  to  encompass  both  aspects  of  the  test  problem. 
Because  of  the  long  history  of  the  use  of  the  testability 
term,  we  will  seldom  draw  a  distinction.  However,  the 
use  of  both  terms  is  significant  in  that  testability  is  not 
independent  of  the  diagnostic  process.  The  writing  of 
test  procedures  cannot  and  should  not  be  done 
separately  from  testability  analyses.  To  do  so,  would  be 
meeting  the  letter  of  the  requirements  without 
considering  the  intent. 

TESTABILITY  AND  DIAGNOSABILITY 
METRICS  OBJECTIVES 

It  is  the  objective  of  the  PI  522  standard  to  provide 
notionally  correct,  inherently  useful,  and  mathematically 
precise  definitions  of  testability  metrics  and 

characteristics.  It  is  expected  that  the  metrics  may  be  Fl9ure  3-  Relationship  Between  Diagnosability  and 

y  Testability 


used  to  either  measure  the  testability  of  a  system,  or  predict  the  testability  of  a  system.  Notionally  correct  means 
that  the  measures  are  not  in  conflict  with  intuitive  and  historical  representations.  Beyond  that,  the  measures 
must  be  either  measurable  or  predictable.  The  former  may  be  used  in  the  specification  and  enforcement  of 
acquisition  clauses  concerning  factory  and  field-testing,  and  maintainability  of  complex  systems.  The  latter  may 
be  used  in  an  iterative  fashion  to  improve  the  factory  and  field-testing  and  maintainability  of  complex  systems. 
The  most  useful  of  all  are  measures  that  can  be  used  for  both.  Because  of  the  last  point,  the  emphasis  will  be  on 
measurable  quantities  (metrics). 

Things  that  can  be  enumerated  by  observation  and  folded  into  the  defined  figures-of-merit  will  be  developed  into 
metrics.  However,  a  few  measures  are  inherently  useful  on  the  design  side  even  if  they  are  not  measurable  in 
the  field  and  they  are  defined  in  a  separate  section  in  PI  522.  The  end  purpose  is  to  provide  an  unambiguous 
source  for  definitions  of  common  and  uncommon  testability  and  diagnosability  terms  such  that  each  individual 
encountering  the  metric  can  know  precisely  what  that  metric  measures. 

ISSUES 


MIL-STD-2165  defined  Fraction  of  Faults  Detected  (FFD)  two  ways.  The  first  is  the  fraction  of  all  faults  detected 
by  BIT/External  Test  Equipment  (ETE).  The  second  is  the  fraction  of  all  detectable  faults  detected  by  BIT/ETE 
[1],  False  alarms  were  excluded  from  the  definition.  From  these  two  variations  grew  many  others.  As  noted  in 
“Organizational-Level  Testability”  [12]  FFD  can  be  defined  as: 

•  Fraction  of  all  faults  detected  or  detectable  by  BIT/ETE 

•  Fraction  of  all  detectable  faults  detected  or  detectable  with  BIT/ETE 

•  Fraction  of  all  faults  detected  through  the  use  of  defined  means.  Defined  means  implies  all  means  of 
detection  that  have  been  identified. 

•  Percentage  of  all  faults  automatically  detected  by  BIT/ETE 

•  Percentage  of  all  faults  detectable  by  BIT/ETE 

•  Percentage  of  all  faults  detectable  on-line  by  BIT/ETE 

•  Percentage  of  all  faults  and  out-of-tolerance  conditions  detectable  by  BIT/ETE 

•  Percentage  of  all  faults  detectable  by  any  means 

One  problem  with  traditional  metrics  is  that  they  are  “overloaded.”  Overloaded  in  this  case  means  that  due  to 
“common  understanding”  of  the  terms,  fine  variations  are  not  specified.  Consequently,  users  of  the  term  do  not 
necessarily  know  the  implications  of  a  precise  definition.  Discussions  of  overloaded  terms  go  on  at  length,  in 
part  because  everyone  in  the  discussion  has  brought  along  a  lot  of  mental  baggage.  Often,  progress  is  only 
made  when  a  neutral  term  is  chosen  and  the  meaning  is  built  from  the  ground  up.  This  overloading  is  so  severe, 
for  example,  that  there  was  no  definition  of  FFD  in  System  Test  and  Diagnosis  [2],  the  authors  preferring  to  use 
Non-Detection  Percentage  (NDP).  FFD  is  the  negative  of  NDP  and  is  equal  to  1-NDP. 

Even  the  number  of  faults  counted  in  the  field  require  a  more  precise  definition.  The  “overloaded”  version  is 
simply  a  count  of  all  the  things  that  failed.  The  quantity  of  all  faults,  as  usually  defined  in  the  industry,  is 
different.  The  quantity  of  faults  detected  by  BIT/ETE,  and  the  quantity  of  faults  detected  exclude  the  occurrence 
of  false  alarms.  Intermittent  faults  are  classified  as  a  single  fault.  Temporary  faults,  those  caused  by  external 
transients  of  noise,  are  not  classified  as  faults. 


FUNCTION  f fd (model : EDIM. edim;  lvl :CEM. level)  :  REAL; 

LOCAL 

diag_count  :  INTEGER; 

diags  :  SET  [0:?]  OF  EDIM. inference 

detect_set  :  SET  [0:?]  OF  OEM. diagnosis  :=  NULL; 

END_LOCAL; 

diag_count  :=  SIZEOF (QUERY (tmp  <*  model ,model_diagnosis 
tmp . level_of_diagnosis  =  lvl); 

REPEAT  I  :=  LOINDEX (model . inf erence )  TO  HIINDEX (model . inference) ; 
diags  :=  QUERY (tmp  <*  model . inf erence [ I ]. con juncts 

(TYPEOF(tmp)  =  ' EDIM. diagnostic_inf erence ' ) ) ; 
diags  :=  diags  +  QUERY (tmp  <*  model . inference [ i ]. dis juncts 
IEEE  Std  1 232.1 -1 997diags  :=  QUERY  (tmp  <*  diags 
tmp.pos_neg  =  negative  OR 
NOT (tmp . diagnostic_assertion  =  'Good')); 
detect_set  :=  detect_set  +  QUERY (tmp  <*  diags . for_diagnosis 
tmp . level_of_diagnosis  =  lvl); 

END_REPEAT ; 

RETURN (SIZEOF (detect_set)  /  diag_count); 

END_FUNCTION ; 


Figure  4.  Sample  Metric  Definition  in  EXPRESS 

Another  aspect  of  the  challenge  is  that  many  metrics  sound  different  but  are  not.  Below  are  some  examples. 

•  Ambiguity  Group  Isolation  Probabilities  is  the  cumulative  probability  that  any  detected  fault  can  be  isolated  by 
BIT  or  ETE  to  an  ambiguity  group  of  size  L  or  less. 

•  Fault  Isolation  Resolution  is  the  cumulative  probability  that  any  detected  fault  can  be  isolated  to  an  ambiguity 
group  of  a  targeted  size  or  less. 

•  Isolation  Level  is  the  ratio  of  the  number  of  ambiguity  groups  to  the  total  number  of  isolatable  components. 


System  Operational  Isolation  Level  is  the  percentage  of  observed  faults  that  result  in  isolation  to  n  or  fewer 
replaceable  units. 


All  of  these  terms  were  and  are  valuable.  The  value  of  these  terms  will  be  increased  with  precise  meanings  for 
each  one. 


ASSUMPTIONS 


The  development  of  a  diagnostic  capability  includes  system  level  analysis.  As  such,  it  is  assumed  that  a  system 
level  approach  is  undertaken,  and  those  diagnostic  strategies  and  testability  criteria  have  been  explicitly 
developed  or  at  least  structured.  These  may  be  variables  in  the  formulation,  but  cannot  be  completely 
undefined.  The  primary  assumptions  are  twofold  and  deal  with  inherent  usefulness  from  prior  experience  and  the 
ability  to  precisely  define  the  term  from  first  principles.  In  some  cases,  we  will  assume  the  existence  of  a 
diagnostic  model  such  as  one  based  on  the  IEEE  1232  series  of  standards.  Metrics  will  be  derived  from  the 
entities  and  attributes  based  on  these  information  models.  In  other  cases,  we  will  rely  on  a  demonstrated  ability 
to  measure  items  related  to  the  testing  at  the  design,  factory,  and  field  levels  concerning  the  maintainability  of 
complex  systems.  In  the  latter  case,  information  models  will  be  developed  as  necessary  to  define  all  relevant 
entities  and  attributes. 

Each  term  carries  with  it  a  number  of  additional  assumptions  (such  as  single  or  multiple  failure)  and  is  explicitly 
dealt  with  on  a  term  by  term  basis  in  the  section  on  metrics  and  characteristics. 

The  FFD  metric  assumes  the  existence  of  a  diagnostic  model  that  ties  tests  (especially  test  outcomes)  to 
potential  faults  in  the  system  analyzed.  Within  AI-ESTATE,  tests,  diagnoses,  and  faults  are  modeled  explicitly  in 
the  common  element  model.  In  addition,  AI-ESTATE  includes  specifications  for  two  diagnostic  models — the  fault 
tree  model  and  the  Enhanced  Diagnostic  Inference  Model  (EDIM).  Due  to  its  generality,  the  EDIM  was  used  to 
define  FFD. 

The  assumptions  used  to  define  FFD  are  as  follows: 

•  We  are  interested  in  the  various  metrics  at  a  particular  level; 

•  A  hierarchical  element  exists  at  a  particular  level; 

•  No  descendant  of  a  hierarchical  element  is  at  the  same  level  as  that  hierarchical  element;  and 

•  At  this  point,  we  don't  care  about  the  ordering  of  the  levels. 

As  an  example,  one  metric  defined  using  the  model  is  Fractions  of  Faults  Detected  (FFD). 

From  these  assumptions  and  the  information  models,  we  can  define  FFD  using  the  procedural  constructs  of 
EXPRESS.  Specifically,  a  function  (FFD)  can  be  specified  as  in  Figure  4.  In  the  process  of  defining  this  one 
metric,  several  issues  were  identified.  These  issues  are  discussed  in  detail  in  [13]. 

OTHER  APPLICATIONS 


Ties  to  Maintenance  Feedback 

In  1993,  a  Project  Authorization  Request  (PAR)  was  submitted  to  the  IEEE  for  new  standards  project  related  to 
specifying  information  and  services  for  test  and  maintenance  information  feedback.  The  Test  and  Maintenance 
Information  Management  Standard  (TMIMS)  project  was  approved  by  the  IEEE  in  early  1994.  The  focus  of  this 
project  was  to  define  exchange  and  service  standards  (similar  to  AI-ESTATE)  which  support  the  test  and 
diagnostic  maturation  process.  In  1998,  due  to  a  lack  of  progress,  the  TMIMS  PAR  was  cancelled. 


AI-ESTATE  continues  to  require  definition  of  exchange  and  service  standards  related  to  test  and  maintenance 
information.  In  1998,  shortly  after  the  cancellation  of  the  TMIMS  PAR,  the  AI-ESTATE  committee  decided  to 
include  test  and  maintenance  information  in  its  scope.  The  approach  will  be  consistent  with  AI-ESTATE  (i.e.,  the 
definition  of  information  models  and  EXPRESS-level  services  derived  from  traversing  the  models).  Further,  it  is 
anticipated  that  the  starting  point  for  the  new  models  will  be  the  dynamic  context  model  in  IEEE  1232.2.  By 
keeping  track  of  the  sequence  of  events  during  a  diagnostic  session,  much  of  the  historical  information  is 
identified  and  captured  that  can  be  used  for  later  diagnostic  maturation. 

Ties  to  Product  Descriptions 

Through  the  1990s,  the  IEEE  has  been  developing  a  family  of  standards  under  the  umbrella  of  “A  Broad  Based 
Environment  for  Test”  (ABBET)  [14],  [15].  An  early  architecture  of  ABBET,  based  on  information  modeling, 
presented  ABBET  as  five  layers:  1)  product  description,  2)  test  requirements/strategy,  3)  test  methods,  4)  test 
resources,  and  5)  instrumentation.  Since  then,  standards  for  the  “lower  layers”  of  ABBET  (i.e.,  layers  3-5)  have 
been  defined;  however,  it  has  long  been  recognized  that  the  major  benefit  from  standardization  will  come  from 
the  “upper  layers”  (i.e.,  layers  1  and  2). 

AI-ESTATE  satisfies  many  of  the  requirements  related  to  layer  two  of  ABBET  (however,  AI-ESTATE  has  never 
been  considered  part  of  the  ABBET  family).  Further,  a  recent  proposal  for  a  new  information  model-based 
standard,  called  the  Test  Requirements  Model  (TeRM),  will  address  specific  concerns  of  test  requirements  [16], 
[17],  Standards  for  the  product  description  layer  have  always  been  problematic  due  to  issues  related  to  the 
revelation  of  intellectual  property.  With  the  combination  of  TeRM,  AI-ESTATE,  and  TMIMS,  it  is  anticipated  that 
intellectual  property  can  be  hidden  from  information  provided  in  standard  form  while  still  supporting  the  test 
engineer  fully. 


CONCLUSION 


Reasoning  system  technology  has  progressed  to  the  point  where  electronic  and  other  complex  systems  are 
employing  artificial  intelligence  as  a  primary  component  in  meeting  system  test  and  verification  requirements. 
This  is  giving  rise  to  a  proliferation  of  Al-based  design,  test,  and  diagnostic  tools.  Unfortunately,  the  lack  of 
standard  interfaces  between  these  reasoning  systems  has  increased  the  likelihood  of  significantly  higher  product 
life-cycle  cost.  Such  costs  arise  from  redundant  engineering  efforts  during  design  and  test  phases,  sizeable 
investment  in  special-purpose  tools,  and  loss  of  system  configuration  control. 

The  AI-ESTATE  standards  promise  to  facilitate  ease  in  production  testing  and  long-term  support  of  systems,  as 
well  as  reducing  overall  product  life-cycle  cost.  This  will  be  accomplished  by  facilitating  portability,  knowledge 
reuse,  and  sharing  of  test  and  diagnostic  information  among  embedded,  automatic,  and  stand-alone  test  systems 
within  the  broader  scope  of  product  design,  manufacture,  and  support. 

AI-ESTATE  was  first  conceived  in  1988  as  a  standard  for  representing  expert-system  rule  bases  in  the  context  of 
maintenance  data  collection.  Since  that  time,  AI-ESTATE  has  evolved  to  be  embodied  in  three  published 
standards  related  to  the  exchange  of  diagnostic  information  and  the  interaction  of  diagnostic  reasoners  within  a 
test  environment.  The  three  standards  have  been  recommended  for  inclusion  on  the  US  DoD  ATS  Executive 
Agent’s  list  of  standard  satisfying  requirements  for  ATS  critical  interfaces.  In  looking  to  the  next  generation,  AI- 
ESTATE  is  expanding  to  address  issues  of  testability,  diagnosability,  maintenance  data  collection,  and  test 
requirements  specification. 
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Abstract 

Field-level  maintenance  of  radar  signature 
treatment  requires  that  non-specialist 
military  personnel  properly  identify  needed 
repairs.  To  simplify  this  task,  an  automated 
method  is  required  that  can  compare  radar 
signature  data  to  baseline  data,  measure  the 
differences,  and  identify  the  source  of 
serious  defects.  Significant  work  has  been 
done  using  artificial  intelligence  (AI) 
techniques  to  simplify  this  diagnostic  task. 
A  portable  measurement  radar  was  used  to 
gather  signature  data  on  a  small  MQM-107D 
target  drone.  One  set  of  data  was  collected 
of  a  baseline  vehicle.  Then  data  was 
collected  after  several  anomalies  were 
introduced,  such  as  an  uncovered  pitot  tube, 
wing  joint  untaped,  or  fastener  screw  not 
tightened.  The  data  was  processed  as  global 
downrange  plots,  and  then  baseline  data  was 
subtracted  from  anomaly  data  and  the 
difference  was  compared  to  signature 
specifications  as  a  function  of  angle.  AI  was 
used  to  identify  signature  defects  that 
require  repair.  The  results  showed  that  an 
Al-aided  diagnostic  tool  could  help  identify 
places  where  signature  treatment  repair  was 
needed.  This  tool  can  be  adapted  to  a  variety 
of  user  and  target  needs. 

Introduction 

Low  Observable  (LO)  systems  require 
specialized  measurement  equipment  to 
ensure  the  LO  characteristics  are  sustained. 
A  portable  diagnostic  measurement  system 
to  assist  maintainers  of  LO  aircraft  is 
required  to  provide  measurement  capability 
to  meet  the  In-Service  radar  cross  section 
(RCS)  measurement  framework,  assess 


mission  readiness  and  capability,  and 
provide  near  real-time  results.  Defect 
isolation,  diagnosis  and  RCS  assessment  are 
important  attributes  of  the  signature 
maintenance  function.  The  purpose  of  this 
effort,  managed  by  the  Advanced 
Technology  Test  Team  (ATTT),  was  to 
develop  a  system,  which  could  measure  an 
item  and  determine  the  signature  health  of 
that  item  with  minimal  human  interaction. 
The  desired  features  include  a  single  system 
with  organic  measurement  and  analysis 
capability,  a  system  that  is  adaptive  to 
various  users  and  LO  assessment  needs,  and 
the  ability  to  use  a  variety  of  methods  to 
determine  corrective  actions.  This  paper 
provides  the  details  of  the  development  of 
automatic  anomaly  detection  software. 

ICON  Downrange  Profile  System 

The  Icon  Downrange  Profile  system  is  an 
anomaly  detection  and  registration  program 
based  on  the  analysis  of  downrange  profiles. 
The  software  provides  graphical  facilities 
for  loading  reference  and  target  data,  finding 
differences  between  the  latter,  building  data 
abstractions  of  these  differences  and 
automatically  matching  the  differences  with 
known  anomalies.  Users  can  also  register 
newly  encountered  differences.  The  system 
allows  graphical  retrieval  and  comparison  of 
registered  anomalies.  The  differencing  and 
matching  phases  of  the  analysis  are  complex 
processes  that  use  clustering  algorithms  to 
create  abstract  representations  of  the 
differences  (known  as  clusters )  which  can 
be  registered  into  an  anomaly  database. 
Menus  are  provided  to  allow  users  to  fine- 
tune  the  various  processing  parameters  in 
each  of  the  phases  of  the  analysis.  The 


clustering  techniques  were  very  successful 
in  recognizing  differences  and  providing  the 
necessary  data  abstraction  paradigms  for 
correctly  retrieving  known  anomalies  from 
the  database  and  distinguishing  between 
them.  The  Icon  system  exploits  Knowledge 
Technologies’  GBB™  and  ChalkBox™ 
products. 

Figure  1  outlines  the  phases  involved  in  data 
analysis.  The  end  result  is  either  a  match 
with  a  known  anomaly(s)  or  the  option  to 
register  a  newly  detected  type  of 
anomaly.  There  are  three  major  phases:  the 
image  analysis  phase,  the  cluster  analysis 
phase  and  the  anomaly  detection/registration 
phase.  Each  of  these  phases  takes  place  at  a 
different  level  of  abstraction. 


Each  of  these  steps  has  proven  crucial  to  the 
overall  process.  The  image  analysis  phases 
provide  data  alignment  and  noise 
elimination.  The  clustering  phases  provide 
not  only  data  abstraction,  but  also  a 
significant  amount  of  data  compression.  The 
anomaly  detection  phases  rely  on  advanced 
matching  facilities. 

The  Icon  analysis  phases  comprise  three 
levels  of  data  abstraction.  These  are  the 
data-point  level,  the  cluster  level  and  the 
anomaly  (composite  cluster)  level.  Figure  2 
outlines  the  three  semantic  levels  and 
indicates  which  analysis  activities  are 
performed  at  each.  Notice  for  example  that 
there  is  a  despeckling  phase  at  both  the  data- 
point  level  and  the  cluster  level  of  the 
overall  analysis. 


At  the  data-point  level,  operations  are 
performed  on  individual  points  in  the 
downrange  profile.  At  the  cluster  level, 
groups  of  data  points  ( clusters )  are  created 
and  operations  are  performed  on  individual 
clusters.  Finally  at  the  anomaly  level,  groups 
of  clusters  (set-composite  clusters )  are 
created  as  composite  objects.  At  this  level, 
operations  are  performed  on  groups  of 
clusters. 


Example/Software  Validation 

To  validate  the  usefulness  of  the  software, 
measurements  were  taken  on  the  MQM-107 
target  drone.  Measurements  were  taken  in  a 
“pristine”  condition  and  then  realistic 
defects  were  implanted  on  the  vehicle.  The 
MQM-107  is  shown  in  Figure  3.  As  an 
example  of  the  detection  process  the  port 
access  screws  were  not  secured  as  shown  in 
Figure  4. 


Figure  3.  MQM-107 


Figure  5  presents  the  output  of  the  anomaly 
detection  process.  As  can  been  seen,  in  the 
difference  data  frame,  the  software 
successfully  found  the  anomaly. 


Figure  5.  Icon  Anomaly  Detection  Software 
Output. 


Summary 

This  initial  effort  of  developing  automatic 
detection  of  radar  signature  defects  was  very 
successful.  Distinguishable  differences  have 
been  detected  and  clusters  generated 
coincided  with  perceived  regions  of 
differences  in  the  target  data.  Future  efforts 
will  include  development  of  a  more 
extensive  anomaly  database,  extending  and 
optimizing  the  clustering  techniques, 
adapting  the  Icon  software  to  ISAR  data, 
and  automating  the  parameter  selection 
process. 
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Program  Objectives 


□  Fabricate  a  prototype  tunable  filter  based  on  liquid  crystal-filled 
Fabry-Perot  etalon  (LCE). 

□  Enable  voltage-controlled,  tunable,  narrow-band  filtering  at  LWIR 
wavelengths 

□  Bandpass  tunable  at  60  Hz  frame  rates 

□  Enable  rapid  scene  characterization  for  camouflaged  target,  or 
chemical  identification 

□  Ability  to  build  up  Hyperspectral  data  cube  with  scanning  software 
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Digital  IR  Microcam  Camera  Set-up 


□  Digital  8-12  micron  IR  Microcam  Camera  mated  with  a  IR  filter  wheel 
holder. 

□  Using  existing  FI,  33°x25°field  of  view  lens 

LWIR  Hyperspectral  Imaging 
JAWS  Symposium 
June  16,  1999 


Ion  Optics,  Inc. 


Hyperspectral  Liquid  Crystal  Etalon 
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Potential  Applications: 
Camouflage  Penetration 
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LWIR  Comparison  of  Target  &  Background 


ERIM  data  shows  typical  paint,  tree  canopy  and  chamoflage  spectra  in  the  8  to  12 
um  range.  We  selected filters  to  capture  data  around  the  SCUD  spectral  feature. 

This  was  compared  to  data  from  pictures  on  either  side  of  the  feature 
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LWIR  Comparison  of  Camouflage  Paints 


FTIR  spectrum  of  camouflage  paints.  Our  measured  data  of  several  paint  samples 
shows  that  the  spectral  features  are  actually  much  larger  then  those  provided  by  ERIM 
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Radiance  from  Top  of  Gas  Cloud  Against  300  K 
Earth  Background,  e=1 


SF6  Gas  Density  (ppm-m) 
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Miminum  Detectable 
Concentration  (ppm-m) 


Potential  Applications: 
Standoff  Plume  Detection 


Minimum  detectable  SF6  Concentration 
(Against  300  K  Earth  background) 


Gas  Plume  Temp  (K) 
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Phase  difference  between  two 
successive  rays  is  the  optical 
path  plus  the  phase  shift  from 
two  reflections 
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Fabry-Perot  Etalon 


Where: 

A  =  mirror  absorption 
R  =  mirror  reflectivity 

n(v)  =  LC  index  of  refraction,  and  is  a  function  of  applied  voltage 
d  =  LC  thickness 

\  =  free  space  wavelength  of  incident  light 
S(A)  =  phase  shift  on  reflection 
G  =  incident  angle  of  rays  entering  LC 
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%  Transmission 


LCE  Transmission  Model 


LCE  Transmission  with  11.25  um  layer 


Wavelength  (um) 


—  —mid 
—1.572 

-  -  -  1.857 


Three  runs  at  n(v)  = 

1.572,  mid,  and  1.857 

Transmission  tuning  range: 
8.7  to  10.55  um 

Bandpass:  0.1  um  FWHM 

Free  Spectral  Range:  2.4um 
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Changing  Gap  Changes 
Interference  Order,  Bandpass 


Reflection  phase  is  critical  to  LCE  gap  size 


1  l  l  i  i  i  I  I  it 


Calculated  from  thin  film 
model  of  dielectric  mirror. 
Phase  shift  is  a  function  of 
wavetength. 
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Apparent  Index  Vs.  Incidence  Angle 


Molecule  Angle,  deg 


Plot  of  effective  index  of  refraction  of  the  LC,  as  the  applied  voltage  causes  the 
molecules  to  tilt.  Note  that  the  effective  index  also  depends  on  the  angle  in  which  the 
light  ray  traverses  the  crystal. 
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System  Issues 


Filter  before  the  lens 
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Bandpass  peak  shifts  radial  across  FPA 


System  Issues 


System  Design:  Relay  Reduces  Stray  Light 


LCE/camera  System  Model 
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Liquid  Crystal  Etalon 
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Task  2:  IR  Camera  Trade-off 


•  Model  calculates  MRTD  at  200  ft.  based  on  LCE 
properties  and  camera  f#,  FOV,  spectral  band 
pass,  etc. 

•  Must  determine  system  limitations  with  best 
availabie  cameras 

•  Cameras  to  be  considered:  QWIP,  HgCdTe, 
Microbolometer,  BST 
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LCE  &  Camera  Test  set-up 
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Conclusions 


□  Rapidly  tunable  narrow  band  LWIR  filter 

□  Convert  LWIR  camera  to 

Hyperspectral  imager 

□  Create  Hyper-data 

cube  with  scanning  software 

□  Applications  include  chemical  and 

target  identification 

□  Suitable  for  terrestrial  and 

space  born  applications 

□  Prototypes  available  in  2000 
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RADAR  SIGNAL/IMAGE  PROCESSING  ENHANCEMENTS  USING  ALPHA- 
STABLE  TECHNIQUES 

Roger  Lee,  Radar  Branch,  Avionics  Department,  NAWC  Aircraft  Division 


ABSTRACT 

In  conventional  radar  signal  and  image  processing,  the  background  clutter  and  noise 
are  assumed  to  follow  the  Gaussian  model.  Recent  research  has  found  that  many  non- 
homogeneous  types  of  clutter  and  noise,  such  as  sea  clutter,  do  not  fit  the  Gaussian  model 
well  because  of  impulsive  outliers  or  the  so  called  “sea  spike.  These  types  of  clutter  and 
noise  lend  themselves  to  a  heavy  tail  in  amplitude  distribution;  consequently,  the 
conventional  matched  filter  does  not  perform  well.  Most  recent  research  has  shown  that 
the  a-stable  model  is  a  better  model,  and  most  radar  clutter  is  modeled  well  by  the  ne¬ 
stable  statistics.  A  robust  family  of  a-stable  matched  filters  is  a  natural  extension  of  the 
conventional  matched  filter  with  the  capability  of  suppression  the  clutter  to  reveal  targets. 
An  optimal  a-stable  matched  filter  extracted  from  this  family  of  filters  is  being  developed 
in  a  simple  closed  form.  This  optimal  a-stable  matched  filter  significantly  improves 
target  detection  in  both  simulated  data  and  real  clutter  data.  Moreover,  the  a-stable 
matched  filter  is  computationally  efficient.  It  can  be  applied  in  wide  varieties  of  radar 
signal  and  image  processing. 

Introduction 

In  conventional  radar  signal/image  processing,  the  background  clutter/noise  is 
assumed  to  follow  the  Gaussian  model.  Indeed  Gaussian  is  a  good  model  for 
homogeneous  clutter/noise  such  as  in  the  desert.  Under  this  assumption,  it  has  been 
shown  that  the  conventional  matched  filter  is  optimal  in  target  detection  (Ref.[l]). 
However,  recent  research  has  found  that  many  types  of  clutter/noise,  such  as  sea  clutter, 
do  not  fit  the  Gaussian  model  well  because  of  impulsive  outliers  or  the  so  called  “sea 
spike”  (Ref.  [2]).  These  types  of  clutter/noise  lend  themselves  to  a  heavy  tail  in  amplitude 
distribution.  Consequently,  the  conventional  matched  filter  does  not  perform  well.  Radar 
engineers  have  been  exploring  other  models  such  as  the  K-distribution  or  the  Weibull 
distribution  to  fit  these  types  of  clutter/noise  (Refs.  [3],  [4]).  Most  recent  research  has 
shown  that  the  a-stable  model  is  a  better  model  and  the  associated  a-stable  matched 
filter  enhances  target  detection  in  radar  signal  and  image  processing  applications  (Refs 
[5],  [9]).  Extended  from  the  conventional  matched  filter,  the  a-stable  m’atched  filter  is 
actually  a  family  of  matched  filters  lending  itself  to  the  robustness  in  filter  optimization. 
This  paper  develops  a  simple  close  form  in  determining  the  optimal  matched  filter  from 
the  family  of  filters. 


1  Approved  for  public  release  :  distribution  is  unlimited 
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Background  :  a-stable  Model  and  a-stable  Matched  Filter 

The  symmetric  a-stable  model  has  three  parameters  (Ref.  [6]);  namely,  the 
location  parameter  5  to  specify  the  point  of  symmetry,  the  dispersion  parameter  y  to 
specify  the  spread  of  data  around  8  ,  and  the  characteristic  exponent  parameter 
a  (  0  <  a  <  2)  to  specify  the  heaviness  of  the  tail.  It  is  to  realize  that,  as  a  special  case, 
when  a  =  2  the  a-stable  model  is  a  Gaussian  model.  Properties  of  the  Gaussian  model 
such  as  the  bell  shape,  symmetry,  and  Central  Limit  Theorem  carry  naturally  to  the 
symmetric  a-stable  model.  Thus,  the  a-stable  model  is  a  natural  extension  of  the 
Gaussian  model.  It  stands  out  from  the  Gaussian  model  by  providing  a  unique  parameter 
a  that  characterizes  the  heaviness  of  the  tail  of  the  clutter.  It  is  shown  in  Ref.  [5]  that  the 
real  sea  clutter  called  “HPC”  (with  radar  look  down  angle  of  8  degrees  and  sea  state  of  3) 
obtained  from  NSWC  fits  on  the  a-stable  model  better  than  the  Gaussian  model,  the  K- 
distribution,  and  the  Weibull  distribution.  The  a-stable  model  is  also  shown  in  Ref.  [5]  to 
fit  four  other  types  of  real  radar  clutter  data  well. 

Let  u(i)  be  the  radar  transmit  waveform  and  x(t)  be  the  received  signal.  Then 
the  conventional  matched  filter  is  expressed  as  : 


u  *  (— t)  <8>  x(t) .  (1) 

and  the  a-stable  matched  filter  (Ref  [9])  is  expressed  as  : 


u*(-t )® 


*(0 

x(tTP 


(2) 


where  ®  is  the  convolution  operation,  *  is  the  complex  conjugate,  and  0  <  p  <  a  . 

It  should  be  noted  that  the  a-stable  matched  filter  is  actually  a  family  of  filters  with 
parameter  p,  lending  itself  to  the  robustness  in  filter  optimization.  The  a-stable  matched  filter 
distinguishes  itself  from  the  conventional  one  by  multiplying  a  suppression  factor  1/  \x(t)\2~p  to 
the  received  signal  for  the  purpose  of  suppressing  the  “spiky”  clutter.  For  a  Gaussian  clutter  ( a  = 
2),  the  optimal  matched  filter  is  the  one  with  p  =  2  in  Eq.(2).  For  a  spikier  clutter  (a  <  2)  the  p 
corresponding  to  the  optimal  a-stable  matched  filter  in  Eq.(2)  should  be  reduced  accordingly  to 
achieve  the  goal  of  suppressing  the  spikier  clutter.  Thus,  the  a-stable  matched  filter  is  a  natural 
extension  of  the  conventional  matched  filter  with  a  parameter  p  as  an  extra  dimension  for 
detection  optimization. 


Performance  of  a-Stable  Matched  Filter 

The  simulated  and  real  data  from  the  popular  linear  chirp  waveform  radar  are  used  to 
evaluate  the  performance  of  the  a-stable  matched  filter  (Ref  [9]).  Specifically,  the  NP-3  SAR 
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waveform  with  linear  chirp  rate  of  -30  MHz/sec,  pulse  duration  of  4  micro-seconds,  and 
sampling  rate  of  125  MHz  is  used  in  the  simulation.  The  following  simulation  steps  are  designed: 

1 .  Select,  for  each  pulse,  512  range  bins  of  simulated  or  real  clutter  data  c(t) ; 

2.  Inject  a  target  at  256-th  range  bin; 

3.  Form  the  received  signal  x(t)  =  s(t)  +  c(t),  where  s(t)  is  the  simulated  received  target 
return  from  the  transmitted  waveform  with  amplitude  adjusted  to  a  desired  SNR 
(signal  to  clutter/noise  ratio); 

4.  Perform  signal  processing  using  the  a-stable  matched  filter  :  y(t)  =  a(x(t))  as  shown 
in  Eq.  (2); 

5.  Declare  target  detection  only  if  jy(256)|  is  larger  than  a  threshold; 

6.  Perform  Monte  Carlo  for  N  pulses. 

With  a  given  SNR  in  step  3,  the  threshold  needed  in  step  5  can  be  computed  in 
accordance  with  selected  PFAs  (Probability  of  False  Alarm).  The  Monte  Carlo  simulation  is  then 
performed  to  result  in  the  ROC  (Receiver  Operating  Characteristics)  curves  in  terms  of  PFA  vs. 
probability  of  detection.  Figure  1  shows  the  ROC  curves  resulted  from  four  a-stable  matched 
filters  using  1024  pulses  of  simulated  clutter  data  with  a  =1.74  ,  y  =  0.97,  8  =  0.0  (same  a,  y 
and  5  as  the  HPC  sea  clutter)  and  SNR  =  -20  dB.  It  is  shown  in  Figure  1  that  the  probabilities  of 
detection  at  PFA  =  0.01  are  0.37,  0.80,  0.83,  and  0.02  for  p  -  0.5, 1.0,  1.5,  and  2,  respectively. 
This  simulation  result  shows  that  by  using  the  a-stable  matched  filter  with  the  parameter  p  in 
between  1  and  1 .5  the  probability  of  detection  increases  dramatically  over  the  conventional 
matched  filter  (p  =  2). 

Note  that  Figures  1  only  shows  the  performance  of  a-stable  matched  filters  for  four  p 
values.  Naturally,  it  is  very  desirable  to  obtain  the  p  corresponding  to  the  optimal  matched 
filter.  This  paper  develops  a  close  form  in  determining  optimal  p. 


Optimal  a-Stable  Matched  Filter 

As  discussed  earlier,  the  family  of  a-stable  matched  filters  is  defined  in  Eq.  (2) 
with  parameter  p.  It  is  unlikely  that  an  analytic  method  can  be  obtained  in  determining 
the  optimal  matched  filter  from  the  family  of  filters.  In  this  paper,  Monte  Carlo 
simulation  approach  is  used  to  estimate  the  optimal  p  with  a  large  number  of  trials,  say  N 
=  5000.  Recall  that  if  a  clutter  is  well  modeled  by  the  a-stable  statistics,  it  will  be 
characterized  by  the  three  parameters  a  ,  y,  and  8,  and  hence  the  optimal  matched  filter  p 
is  a  function  of  these  three  parameters.  It  is  shown  that  actually  the  optimal  a-stable 
matched  filter  depends  only  on  the  parameter  a  .  Figure  2,  in  a  simulation  run  with  a  = 
1.5, 1.6, 1.7  1.8, 1.9,  1.92,  1.94, 1.96, 1.98,  and  2.0,  shows  the  performance  curves  of  the 
family  of  a-stable  matched  filters  in  terms  of  probability  of  detection  for  different  values 
of  p.  Through  extended  analysis  of  the  performance  curves,  the  following  properties  are 
observed: 
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1 .  the  performance  curves  are  smooth, 

2.  the  a-stable  matched  filter  can  significantly  outperforms  the  conventional 
matched  filter  (p= 2);  this  is  especially  true  for  spikier  clutter, 

3.  there  is  a  plateau  of  optimal/near  optimal  region  for  each  performance  curve;  i.e. 
there  is  a  wide  region  of  p  for  which  the  match  filters  are  optimal  or  near 
optimal, 

4.  the  optimal  a-stable  matched  filter  is  independent  of  PFA, 

5.  the  optimal  a-stable  matched  filter  is  independent  of  SNR. 

The  above  phenomena  and  analysis  reveal  that  if  radar  clutter  fits  the  a-stable  model, 
the  optimal  a-stable  matched  filter  is  solely  a  function  of  the  parameter  a  ,  i.e.  Po  =J{ a), 
where  Po  is  the  p  in  Eq.(2)  corresponding  to  the  optimal  matched  filter.  Naturally,  it  is 
very  desirable  to  find  a  close  form  for  the  function  /.  For  a  =  1 .5, 1 .6, 1 .7, 1 .8, 1 .9, 1 .92, 
1 .94, 1 .96, 1 .98,  and  2.0,  the  simulated  optimal  Po  are  indicated  by  on  the 
performance  curves  in  Figure  2..  It  is  also  observed  that  when  a  =  1.5,  Po  ~  3a/4  =  1.125, 
and  when  a  =  2,  Po  =  2.  One  simple  family  (with  parameter  q  >  1)  of  functions  that  pass 
through  these  two  points  and  fits  simulated  optimal  (a,p)  data,  indicated  by  on  the 
performance  curves  in  Figure  2,  is  : 

Po  =  f(a )  =  1 . 125  +  0.875  *  (1  -  (1  -  2  *  (a  - 1 ,5))v?) . (3) 

Through  vast  simulation  runs,  it  is  found  that,  with  q  =  3.5  ,  Eq.(3)  provides  an 
excellent  close  form  in  estimating  the  optimal  Po.  These  optimal  Po  via  Eq.(3)  for 
various  a  values  are  shown  in  Table  1 .  They  are  indicated  by  “o”  on  the  performance 
curves  in  Figure  2.  It  is  to  note  that  even  though  the  closed  form  optimal  and  the 
simulated  optimal  may  not  coincide  with  each  other  for  all  a-stable  clutter  they  are  both 
on  the  plateau  of  optimal/near  optimal  region.  In  fact,  from  Figure  2,  the  differences  in 
probability  of  detection  between  them  for  all  performance  curves  are  all  within  0.004. 
Thus  the  closed  form  optimal  Po  derived  from  Eq.(3)  provides  a  simple  and  quick  way  to 
extract  an  optimal  matched  filter  out  of  the  entire  family  of  a-stable  matched  filters. 

Using  this  optimal  matched  filter  for  the  target  detection  processing  via  Eq.(2),  the 
optimal  a-stable  matched  filter  outperforms  the  conventional  matched  filter  significantly. 
Taking  from  the  results  shown  in  Figure  2,  Table  1  shows  the  gain  in  probability  of 
detection  of  the  optimal  a-stable  matched  filter  over  the  conventional  matched  filter  for 
different  a-stable  clutter.  As  expected,  the  spikier  the  clutter  (smaller  a  value)  the  more 
gain  the  optimal  matched  filter  produces. 


a 

1.5 

1.6 

1.7 

1.8 

1.9 

1.92 

1.94 

1.96 

1.98 

2.0 

Po  (optimal) 

1.125 

1.179 

1.482 

2.0 

SNR 

ism 

MM 

-19 

mam 

-18 

-17 

Prob 

ism 

EJjjggg 

0.480 

0.527 

0.558 

gUSSIM 

0.640 

Prob  Gain 

0.761  | 

|  0.704  | 

|  0.633  | 

|  0.572 

|  0.535  | 

0.452 

0.411 

0.375 

j  0.204  j 

0 

Table  1  Detection  probability  by  the  optimal  matched  filter  vs.  the  conventional  filter 


4 


Performance  of  Optimal  a-Stable  Matched  Filter  on  Real  Data 

NP3-SAR  (Synthetic  Aperture  Radar)  data  available  in  NAWCAD  Radar  Laboratory  was 
used  to  evaluate  the  performance  of  the  optimal  a-stable  matched  filter  on  real  data.  A  subset  of 
L-band  SAR  sea  clutter  data  known  as  the  “Puerto  Rico  19p51hh”  of  size  512  range  bins  by  2048 
pulses  was  observed.  Fitting  this  sea  clutter  data  by  the  a-stable  model  pulse  by  pulse,  except  for 
a  few  anomaly  pulses,  the  parameter  estimation  of  a  is  fairly  consistent,  with  an  average  value 
of  1.759  and  standard  deviation  of  0.1.  With  this  a  the  corresponding  optimal  a-stable 
matched  filter  via  Eq(3)  is  the  one  with  Po  =  1.2897.  By  using  the  Puerto  Rico  real  data  for 
Monte  Carlo  simulation,  the  optimal  a-stable  matched  filter  outperforms  the  conventional 
matched  filter  by  a  gain  of  0.60  in  probability  of  detection,  which  is  comparable  to  the  result 
shown  in  Table  1 . 

a-Stable  Matched  Filter  for  Image  Formation 

SAR  provides  2-dimensional  imagery,  of  which  the  axes  are  commonly  referred 
to  as  the  range  and  the  azimuth.  To  form  a  SAR  image  two  basic  processing  steps  are 
needed;  namely,  the  range  compression  and  the  azimuth  compression.  Each  compression 
is  processed  using  an  appropriate  matched  filter.  If  the  clutter  of  the  image  is  spiky  and 
the  clutter  fits  a  particular  a-stable  model  well,  then  instead  of  using  the  conventional 
matched  filter,  one  can  expect  that  the  use  of  appropriate  a-stable  matched  filter(s)  for 
either  or  both  range  and  azimuth  compression  would  result  in  improvement  in  target 
detection.  To  test  the  efficacy  of  the  a-stable  matched  filter  in  image  processing,  a 
512x512  simulated  SAR  raw  data  is  created.  The  data  contain  simulated  a-stable  clutter 
pulse  by  pulse  with  a  =  1 .5,  and  a  simulated  weak  target  at  the  center  of  the  image  with 
SNR  =  -35.  The  conventional  image  formation  process  is  then  performed  on  the  data  to 
form  the  image.  The  resulting  image  shows  no  target,  just  the  noisy  clutter..  An  a-stable 
image  formation  matched  filter  consisting  of  the  range  compression  filter  with  optimal  Po 
derived  from  Eq.(3)  and  the  conventional  azimuth  compression  matched  filter,  is  then 
applied  to  the  same  data.  The  resulting  image  shows  a  recognizable  target  with  the  clutter 
being  successfully  suppressed. 

The  above  result  is  appealing  but  more  work  needs  to  be  done  in  quantifying  the 
performance  of  a-stable  method  versus  the  conventional  method  in  terms  of  standard 
measurements  such  as  location  registration,  phase  accuracy,  resolutions,  mainlobe  to 
sidelobe  ratio,  integrated  mainlobe  to  sidelobe  power  ratio  etc.  In  addition,  real  data 
should  be  tested  to  conclude  the  effectiveness  of  a-stable  image  formation  matched 
filters. 
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Conclusion 


In  general  most  radar  clutter  are  modeled  by  the  a-stable  statistics  well.  Robust 
family  of  a-stable  matched  filters  is  a  natural  extension  of  the  conventional  matched 
filter.  An  optimal  a-stable  matched  filter  is  developed  in  a  simple  closed  form  in  this 
paper.  This  optimal  a-stable  matched  filter  significantly  improves  target  detection  in 
probability  of  detection  for  simulated  data  as  well  as  real  clutter  data.  Moreover,  the  a- 
stable  matched  filter  is  computationally  efficient.  This  technology  can  be  used  in  wide 
varieties  of  radar  signal  and  image  processing.  The  process  of  implementing  the  a-stable 
technology  in  a  platform  is  very  simple;  it  can  be  outlined  by  the  following  three  steps  : 

(a)  periodically  model  the  received  signal  to  update  the  a  parameter; 

(b)  compute  a  new  optimal  a-stable  matched  filter  using  Eq.(3); 

(c)  employ  the  new  optimal  a-stable  matched  filter  (i.e.  new  optimal  Po)  in 
Eq.(2)  for  target  detection. 
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Pd  -  probability  of  detection 


Alpha-stable  clutter  with  alpha  =  1 .74  SNR  =  -20 


Pfa  -  probability  of  false  alarm 


Figure  1  Performance  of  a-Stable  Matched  Filter  on  Simulated  Clutter  (PFA  vs  Pd) 
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(a)  a  =  1.5,  1.6, 1.7, 1.8,  1.9,  2.0 


(b)  a  =  1.92, 1.94, 1.96, 1.98, 2.0 


Figure  2.  Performance  of  the  family  of  a-Stable  Matched  Filters  for  simulated 
clutter  with  a  =  1.5, 1.6, 1.7, 1.8, 1.9,  1.92, 1.94, 1.96, 1.98,  and  2 


3D  Radar  Signature  Visualization  of  Air  Vehicles 
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One  of  the  challenges  in  displaying  radar  signature  data  is  to  present  the  data  in  an  intuitive 
way  so  that  the  radar  return  levels  identify  the  source  of  the  radar  returns.  This  paper 
describes  a  method  of  visualizing  radar  signature  data  using  three-dimensional  computer 
aided  design  (CAD)  models. 

Radar  signature  data  can  be  presented  in  one  dimension,  as  a  dBsm  level  as  a  function  of 
vehicle  aspect  angle.  In  a  synthetic  aperture  radar  image,  data  is  presented  in  a  two- 
dimensional  image:  as  an  intensity  level  represented  by  a  color  located  in  both  vehicle  down 
range  and  cross  range.  When  the  radar  antennas  are  translated  both  vertically  and 
horizontally,  radar  data  is  located  three-dimensionally  in  down  range,  cross  range,  and 
vertical  range.  This  is  useful  because  it  provides  for  a  more  precise  location  of  point  scatters, 
which  would  aid  a  technician  tasked  to  repair  a  signature  flaw.  The  point  scatterer  can  be 
identified  precisely  because  the  ambiguity  in  vertical  range  is  eliminated.  Also,  clutter  due  to 
ground  bounce  and  bounce  off  of  the  ceiling  can  be  separated  from  vehicle  returns  in  the 
vertical  dimension. 

The  Office  of  Naval  Research  and  the  Naval  Air  Warfare  Center,  Weapons  Division, 
Advanced  Antenna  Technology  Branch,  China  Lake,  California,  developed  the  Miniature  High 
Speed  Radar,  or  MHSR,  used  for  collecting  this  3D  data.  Sensor  Concepts,  Inc.,  Livermore, 
California,  developed  the  3D  software.  The  data  was  collected  using  a  1-38  at  Edwards  AFB, 
and  a  BQM-74E  target  drone  at  Naval  Air  Station  Point  Mugu. 

The  radar  is  a  low-power  linear  FM  homodyne  radar,  and  is  especially  suited  for  collecting 
radar  signature  data  of  vehicles  inside  untreated  hangars,  due  to  its  low  output  power  and 
high  accuracy.  The  MHSR  was  set  up  to  image  the  aircraft  at  X-band,  around  a  10  GHz 
center  frequency.  Bandwidth  was  3  GHz  for  the  BQM-74E  measurement,  with  a  20  ft  by  30  ft 
by  30  ft  image  zone,  and  2  to  3  inch  resolution.  Bandwidth  was  1  GHz  for  the  T-38 
measurement  in  order  to  provide  a  larger  image  zone,  and  resulted  in  5  to  6  inch  resolution. 

The  T-38  was  imaged  while  sitting  on  its  landing  gear  in  a  maintenance  hangar  at  Edwards 
AFB,  as  shown  in  Figure  1 .  Radar  absorbent  foam  was  used  to  block  the  return  from  the 
landing  gear.  The  positioner  translated  the  radar  antennas  5  ft  horizontally  and  5  ft  vertically. 

The  BQM-74  target  drone  was  measured  inside  a  maintenance  hangar  at  Point  Mugu.  The 
drone  was  placed  on  a  5  ft  column  of  expanded  polystyrene  foam.  Radar  absorbent  foam 
was  used  to  decrease  the  ground  bounce  in  front  of  the  drone. 
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Figure  1  The  radar  and  positioner  in  place  to  measure  the  T-38  in  the  hangar. 


The  3D  computer-aided  design  model  was  in  the  common  .3ds  file  format.  The  number  of 
facets  is  a  measure  of  the  complexity  of  CAD  models.  The  T-38  model,  shown  in  Figure  2, 
had  over  2000  facets.  The  models  were  complex  enough  to  accurately  represent  the  aircraft 
without  being  so  complex  as  to  unnecessarily  slow  down  the  software  that  mapped  the 
returns  to  the  surface  of  the  CAD  model.  The  software  used  to  create,  manipulate,  and 
display  3D  models  was  VRT :  a  virtual  reality  software  that  is  available  commercially  from 
Superscape. 


Figure  2.  The  3D  CAD  model  of  the  T-38  as  depicted  using  VRT  software. 

The  3D-image  visualization  process,  depicted  in  Figure  3,  begins  by  creating  or  importing  the 
CAD  model  of  the  aircraft  into  the  VRT  virtual  reality  software.  The  3D  CAD  model  is  aligned 
to  the  2D  overlay  used  to  map  the  MHSR  data  in  cross  range  and  down  range.  Then  the  data 
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collected  by  the  MHSR  is  defined  in  cross  range,  downrange,  and  vertical  range.  The  data  is 
then  mapped  where  it  intersects  with  the  CAD  model  surface,  using  a  texture  approach  as 
shown  in  Figure  4.  The  texture  approach  maps  pixels  of  color  based  on  the  resolution  size  of 
the  radar  data  rather  than  only  one  color  per  CAD  model  facet.  This  approach  permits 
depiction  of  the  radar  data  to  be  independent  of  the  CAD  model  facet  size. 


Figure  3.  Procedure  used  to  map  radar  signature  data  on  a  3D  model. 


Facet  Approach 


Texture  Approach 


Figure  4.  The  texture  approach  to  mapping  colors  to  the  3D  model  is  independent  of  facet  size. 
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The  VRT  software  then  creates  bitmaps  of  the  pixels  that  map  onto  the  facets  of  the  CAD 
model.  The  VRT  software  also  provides  the  capability  to  view  the  CAD  model  in  3D 
perspective  and  show  it  from  any  viewing  angle. 

Shown  in  Figure  5  is  a  typical  2D  image  created  from  MHSR  data  showing  the  outline  of  the 
T-38  in  cross  range  and  downrange.  Note  that  all  returns  in  vertical  range  collapse  onto  the 
display  plane.  Some  radar  return  could  come  from  reflections  from  the  ceiling  or  floor,  and 
would  be  mapped  onto  the  aircraft  outline. 


Using  3D  data  eliminates  the  vertical  range  ambiguity  problem,  because  returns  are  mapped 
in  the  vertical  dimension  as  well  as  in  cross  range  and  downrange. 


Downrange  (in) 


Crossrange  [in] 


Figure  5.  Typical  2D  image  using  MHSR  data. 

The  VRT  software  was  used  to  generate  the  CAD  model  in  Figure  6.  This  figure  depicts  the 
returns  painted  onto  the  external  facets  of  the  CAD  model  of  the  BQM-74E.  Note  the  large 
return  from  the  nose  area.  Note  also  that  the  return  due  to  the  mounting  lugs  and  parachute 
cable  are  mapped  to  the  top  of  the  vehicle. 
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Figure  6.  BQM-74E  model  with  radar  returns  mapped  onto  the  surface. 

Figure  7  illustrates  a  T-38  model  with  the  radar  returns  mapped  on  it.  The  engine  inlets  and 
canopy  were  covered  with  RAM  to  reduce  their  returns.  The  left  view  shows  returns  mapped 
to  the  top  of  the  wing,  and  the  right  view  shows  the  returns  mapped  to  the  bottom  of  the  wing 
clearly  showing  the  effect  of  the  landing  gear  and  flap  brackets. 


Figure  7.  Note  the  difference  in  returns  mapped  to  the  top  and  the  bottom  of  the  T-38  model. 


Another  tool  built  into  the  3D  visualization  software  was  the  ability  to  “flag”  the  highest 
returns.  The  user  can  specify  the  number  of  flags.  Figure  8  shows  the  eight  highest  returns 
for  this  configuration.  The  engine  inlets  were  covered  with  RAM  to  eliminate  their  high  return. 
Note  the  flags  that  appear  “submerged”  on  the  wing  skin.  These  flags  denote  some  of  the 
highest  return  areas  that  were  not  mapped  to  the  skin  of  the  3D  CAD  model,  specifically  the 
shrouded  landing  gear. 


Figure  8.  Flags  can  be  depicted  to  show  the  location  of  the  highest  returns. 


Figure  9.  Multiple  bounces  of  radar  energy  in  the  inlet  causes  the  return  to  be  mapped  downrange. 
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Multi-bounce  phenomena  are  a  challenge  when  mapping  returns  to  a  3D  CAD  model.  Multi¬ 
bounce  returns  are  delayed  in  time  and  therefore  are  mapped  farther  downrange  than  the 
point  of  the  original  return.  The  returns  mapped  on  the  tail  surface  of  the  T-38  in  Figure  9, 
were  caused  by  multiple  bounces  in  the  engine  inlets.  One  way  to  depict  this  multi-bounce 
phenomenon  is  to  provide  a  surface  to  map  to,  such  as  a  horizontal  plane  that  can  be  moved 
vertically. 

In  Figure  10,  only  returns  that  could  not  be  mapped  to  the  surface  of  the  CAD  model  are 
displayed  mapped  to  the  horizontal  plane  as  it  moves  vertically.  The  high  return  from  the 
engine  inlet  cavity  is  displayed  as  bright  colors  aft  of  the  aircraft  fuselage.  The  high  return 
also  raises  the  noise  floor,  which  results  in  the  blue  flash  in  front  of  the  engine  inlet. 


Figure  10.  The  horizontal  plane  provides  a  surface  to  map  multiple-bounce  radar  returns  that  are 

delayed  in  time. 

In  conclusion,  mapping  radar  returns  to  the  surface  of  a  3D  CAD  model  provides  an  intuitive 
way  of  visualizing  the  sources  of  radar  returns.  Since  scanning  the  antenna  in  both  vertical 
and  horizontal  dimensions  collects  three-dimensional  data,  the  vertical  ambiguity  present  in 
most  traditional  2D  images  is  eliminated.  Specialized  3D  software,  developed  by  SCI  for  the 
Office  of  Naval  Research,  provides  the  link  between  3D  radar  return  data  and  commercial-off- 
the-shelf  virtual  reality  software  available  to  view  CAD  models.  Multiple-bounce  returns  can 
be  depicted  using  a  moving  plane  to  map  returns  delayed  in  time,  and  therefore  outside  of 
the  CAD  model  surface. 
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ABSTRACT 

The  purpose  of  the  Electronic  Distribution  of  Technical  Information  via  Satellite  (EDTIS)  is  to  link 
developing  technologies  to  provide  an  increased  capability  for  flight-line  maintenance-crews  and  flight- 
crews.  This  capability  is  the  greatly  improved  access  to  technical  information  at  a  greatly  reduced  cost. 
Enabling  technologies  are:  the  digitization  and  standardization  of  pertinent  technical  information  and 
graphics;  remote  access  of  technical  information  over  satellite  networks;  and  the  utilization  of  portable 
maintenance  aids  (PMA).  The  Advanced  Avionics  Multi-Radar  Software  Support  System  (AAMRSSS) 
performed  a  proof-of-concept,  called  the  AC-130U  System  2000  Demonstration  Program,  that  digitized 
technical  orders  and  accessed  them  via  remote  sites  between  Robins  AFB,  Georgia  and  Hurlburt  Field. 
Florida.  EDTIS  will  build  upon  this  demonstration  by  providing  highly  desirable  technical  documentation 
to  flight  line  repair  crews  for  Special  Operation  Forces  (SOF)  Aircraft  while  providing  the  latest  PMA 
interface  to  the  satellite  technical  information  links.  This  paper  will  review  the  AC-130U  System  2000 
Demonstration  Program  and  provide  an  overview  of  the  EDTIS  program.  The  paper  will  also  discuss 
some  of  the  relevant  technical  advancements  being  taken  advantage  of  to  provide  an  EDTIS  capability  to 
SOF.  The  paper  will  conclude  with  a  discussion  of  the  potential  savings  of  using  these  types  of  systems, 
and  other  technologies  that  might  be  leveraged  to  make  it  more  potent. 


INTRODUCTION 

One  of  the  major  impacts  of  Acquisition  Reform,  is  the  necessity  to  reduce  life  cycle  costs.  The  cost  of 
maintenance  is  a  significant  factor  in  life  cycle  costs.  Maintenance  support  of  many  weapon  systems 
currently  requires  the  printing  and  distribution  of  thousands  of  pages  incorporated  into  the  Technical 
Orders  and  their  regular  revisions  in  order  to  support  the  weapon  system  at  various  deployment  sites. 
This  effort  is  both  cumbersome  and  costly  and  fails  to  provide  current  maintenance  data  in  a  timely 
manner.  Maintenance  delays  are  introduced  as  correct  Technical  Order  information  is  sought.  Incorrect 
maintenance  actions  are  sometimes  taken,  resulting  in  “good”  Line  Replaceable  Units  (LRUs)  being 
pulled,  due  to  lack  of  correct  repair  information.  The  net  result  is  a  costly  system,  in  need  of  a  better  way. 


ANALYSIS  OF  THE  PROBLEM 

The  rapid  growth  in  complexity  of  weapon  systems  is  straining  the  conventional  methods  of  maintenance 
document  generation,  revision,  and  transmission  to  maintenance  personnel.  The  existing  system  of  paper 
documents  has  many  inherent  delays  as  a  distribution  system.  These  delays  include  the  publishing, 
distribution,  and  warehousing  of  the  documents.  The  use  of  change  pages  introduces  another,  expensive 
layer  of  labor  intensive  efforts.  It  is  reported  that  the  US  Air  Force  system  requires  14  months  between 
the  approval  of  document  changes  and  their  release  to  the  maintenance  personnel.  In  addition,  the 
requirement  to  maintain  and  staff  multiple  libraries  has  a  major  cost  impact. 


1 


A  SOLUTION  WITH  MANY  BENEFITS 


Electronic  document  generation  and  distribution  offers  the  opportunity  to  implement  many  worthwhile 
changes  beyond  simply  increasing  the  speed  of  document  distribution.  A  properly  configured  system  can 
provide  instantaneous  release  of  an  authorized  document  anywhere  in  the  world.  In  addition,  it  gets  the 
information  to  the  user,  the  flight  line  maintenance  technician. 

But  it  can  do  much  more.  It  can  provide  multiple  levels  of  linked  graphics  and  text  to  assist  in 
understanding  how  to  maintain  unfamiliar  equipment.  It  can  prompt  additional  information  to  help  probe 
in  unfamiliar  areas,  and  it  can  stand  aside  when  available  expertise  is  present.  In  order  to  realize  the  full 
advantage  of  electronic  documents,  an  infrastructure  must  be  installed  which  provides  the  required 
capability.  Figure  1  diagrams  the  physical  architecture  of  an  electronic  distribution  network  from  a 
central  (national)  facility  to  one  of  N  flight  line  maintenance  stations. 


SATELLITE 


FLIGHT  LINE  CENTRAL  NODE  VSAT 

STATION  FOR  WIRELESS  REMOTE 

LAN  NODE 

AIR  FIELD 


VSAT 

HUB 

CENTRAL  DOCUMENT 
FACILITY 


Figure  1 

This  network  allows  the  transmission  of  data  from  the  Very  Small  Aperture  Terminal  (VSAT)  hub  to  the 
remote  VSATs  at  very  high  rates  to  service  multiple  users.  The  VSAT  remote  node  parses  this  high  rate 
data  stream  and  passes  a  relatively  small  amount  of  the  data  over  the  wireless  LAN  to  the  flight  line 
stations.  A  flight  line  system  with  a  wireless  modem  connection  to  a  central  data  base  storage  system  on 
the  air  field  could  be  configured  using  a  small  commercial  computer,  such  as  a  hand-held  personal 
maintenance  assistant  (PM A)  with  cordless  technology. 


SYSTEM  2000  DEMONSTRATION  PROGRAM 

This  effort  demonstrated  several  necessary  steps  for  achieving  the  goal  of  the  elimination  of  the  printing 
and  distribution  difficulties.  These  difficulties  are  associated  with  weapon  system  Technical  Orders 
(TOs).  This  is  accomplished  through  the  paperless  electronic  delivery  of  these  documents  directly  to  the 
maintainer  at  any  location  on  the  globe  equipped  with  a  simple,  inexpensive  VSAT.  The  on-line 
distribution  of  maintenance  related  support  data  is  a  feature  of  the  Raytheon  System  2000  Precision 
Maintenance  System. 

In  the  System  2000  architecture,  the  documents  are  maintained  in  a  central  CONUS  (Continental  United 
States)  repository  and  are  delivered  in  the  latest  revision  appropriate  to  the  aircraft  configuration  specified 
by  the  maintainer.  The  electronic  Technical  Orders  are  in  the  form  of  Class  IV  Interactive  Electronic 
Technical  Manuals  (IETMs)  with  electronic  enhancements  to  greatly  reduce  the  time  required  by  the 


2 


maintainer  in  performing  his  function.  The  Technical  Orders  are  delivered  directly  to  the  maintainer  at 
the  flight  line  via  a  small  hand  held  wireless  Portable  Maintenance  Aid  linked  directly  to  the  local  VS  AT 
receiver/transmitter. 

The  initial  phase  of  this  project  was  sponsored  by  the  Warner  Robins  Air  Logistic  Center  (WR-ALC/LUE) 
and  funded  by  USAF  Productivity,  Reliability,  Availability  and  Maintainability  (PRAM)  Office  of  Wright- 
Patterson  AFB  (WPAFB).  The  project  provided  a  demonstration  of  commercial  satellite  applicability  in 
the  Department  of  Defense  environment  for  real-time  on-line  access  and  distribution  of  Technical  Orders 
in  IETM  format  to  field  users  using  transportable  VSATs. 

A  VSAT  Terminal  and  user  PC  console  was  installed  at  Hurlburt  Field,  as  well  as  two  loaned  VSAT 
Terminals,  one  each  to  the  second  field  site  at  Warner  Robins  ALC,  Robins  AFB,  and  the  central  data 
repository  site  at  the  Raytheon  office.  The  equipment  at  each  of  the  three  sites  was  configured  to  meet  the 
requirements  of  each  site.  A  two-way  communications  link  via  contractor-operated  satellite  was  also 
provided.  When  the  satellite  communications  network  was  placed  into  service,  the  three  sites  were  put 
into  their  “permanent”  configuration,  enabling  communication  among  the  sites.  In  establishing  satellite 
network  operation,  many  parameters  were  analyzed,  such  as  projected  bandwidth  requirements,  frequency 
availability,  pointing  angles,  etc.  The  satellite  network  was  then  made  available  24  hours  per  day,  7  days 
per  week,  on  an  as-desired  basis,  between  the  three  sites  noted  above,  for  the  designated  period  of 
performance. 

A  central  repository  of  Electronic  Technical  Orders  was  established  at  the  Raytheon  Warner  Robins  office. 
Data  installed  at  the  central  repository  included  a  limited  number  of  Technical  Orders  in  IETM  format  for 
the  AC-130U  Gunship,  as  developed  by  the  Technical  and  Management  Services  Corporation  (TAMSCO) 
for  the  sponsor  organization. 

It  was  successfully  demonstrated  that  IETMs  could  be  transferred  between  locations  via  the  satellite 
communications  network.  The  System  2000  user  interface  provided  the  basic  capability  to  access  IETMs, 
initiate  their  transfer  to  and  from  the  central  database,  and  access  the  Advanced  Integrated  Maintenance 
Support  System  (AIMSS)  tool  to  view  and  utilize  the  IETMs. 

The  IETMs  selected  for  use  in  the  demo  were  thought  to  be  Class  II,  fully  functioning,  and  complete. 
Unfortunately,  several  of  the  documents  were  actually  supplements,  and  the  main  documents  had  to  be 
retrieved.  In  addition,  many  of  the  diagrams  included  were  not  of  the  quality  needed  to  be  easily  brought 
up  to  Class  IV.  Therefore,  more  work  was  required  than  anticipated,  in  converting  the  documents  to 
Class  IV.  In  retrospect,  it  may  have  been  better  to  start  with  the  paper  documents,  at  least  for  consistency 
expectations.  Once  the  IETMs  were  converted  to  Class  IV,  they  functioned  well  as  part  of  the  System 
2000  demonstration. 

By  using  interactive,  electronic  documentation,  the  user  is  able  to  find  the  information  needed  quickly. 
Hot  spots  on  the  diagram  link  to  sources  detailed  information,  as  seen  in  Figure  2. 

The  next  snapshot  (Figure  3)  demonstrates  how  safety  warnings  have  greater  impact  in  interactive 
electronic  documentation. 

From  the  perspective  of  the  IETM  user,  there  were  not  enough  IETMs  provided  to  allow  them  to  evaluate 
the  quality  of  the  IETMs  themselves.  Although  the  main  concept  of  the  demo  was  to  demonstrate  IETM 
distribution  via  the  satellite  network,  it  is  important  to  provide  enough  data  samples  to  all  of  the  users 
throughout  the  demonstration  system  to  facilitate  a  system-wide  evaluation.  The  user  community  has 
identified  several  IETMs,  and  these  are  being  retrieved.  They  are  in  paper  format.  This  will  provide  a 
good  indication  of  the  end-to-end  processing  needed  to  replace  existing  paper  Technical  Orders  with  Class 
IV/V  IETMs. 

This  task  demonstrated  many  aspects  of  how  the  System  2000  Precision  Maintenance  System  is  a  viable 
and  practical  approach  to  the  urgent  need  to  reduce  the  cost  of  Operations  and  Maintenance  of  USAF 
aircraft. 
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Figure  2 


Figure  3 
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AN  OVERVIEW  OF  EDTIS 


One  of  the  significant  benefits  of  the  System  2000  Precision  Maintenance  System  is  its  ability  to  adapt  to 
the  requirements  of  each  user  community,  while  maintaining  its  predominantly  Commercial-Off-The- 
Shelf  (COTS)  architecture.  Requirements  for  each  deployment  vary  due  to  a  variety  of  reasons,  including: 

•  Physical  architecture  of  the  user  community,  such  as  the  number  and  location  of  sites,  both 
local  and  remote, 

•  Amount  of  technical  information  to  be  accommodated  by  the  system, 

•  Frequency  of  information  updates,  and 

•  Security  requirements. 

EDTIS,  as  well  as  its  predecessor  AAMRSSS,  performed  an  analysis  of  the  current  process  of  deploying, 
referencing,  and  maintaining  Technical  Orders  of  Special  Operations  Forces  (SOF)  Aircraft  at  Hurlburt 
Field,  and  prepared  an  initial  System  2000  architecture  definition  based  on  the  needs  of  the  user.  This 
architecture  was  implemented  on  a  small  scale,  allowing  user  feedback  to  determine  how  well  the  initial 
design  performs,  as  well  as  areas  that  need  improvement  or  adjustments. 

It  is  important  to  note  that  while  the  initial  implementation  of  an  electronic  information  distribution 
system  is  thought  of  in  terms  of  improving  the  infrastructure  of  the  current  process,  the  implementation 
actually  allows  processes  to  be  redesigned  from  the  ground  up.  Hence,  the  analysis  of  an  installation 
should  have  two  distinct  facets: 

1 .  A  comparison  of  the  current  process  using  the  new  infrastructure  vs.  the  existing 
infrastructure, 

2.  A  complete  re-evaluation  of  the  current  process,  to  seek  ways  that  the  new  infrastructure 
could  support  elimination  of  costly  and  outdated  portions  of  the  process. 

The  first  is  an  evaluation  of  the  evolutionary  merits  of  the  new  system.  This  is  critical,  because  it  is  not 
reasonable  to  expect  that  a  process  in  day-to-day  use  can  be  replaced  with  a  radically  new  process 
overnight,  regardless  of  how  well  it  performs.  The  second  is  also  critical,  though  more  difficult  to 
accomplish.  By  thinking  out-of-the-box,  real  and  substantial  cost  savings  can  be  achieved.  This  longer- 
term  vision  needs  to  be  well  coordinated  to  minimize  disruption  to  the  users. 

As  such,  EDTIS  focuses  on  two  key  areas: 


•  Technical  Documentation  Usability 

•  Technical  Documentation  Accessibility 

In  keeping  with  the  objectives  of  the  EDTIS  program,  the  technical  documentation  studied  refers  to  paper 
TOs  and  electronic  IETMs,  although  much  of  the  results  of  the  EDTIS  program  can  be  applied  to 
countless  types  of  information,  from  software  documentation  to  logistics  data. 


EDTIS  TECHNICAL  DOCUMENTATION  USABILITY 

IETMs  have  many  advantages  over  paper  TOs.  As  a  replacement  for  TOs,  they  minimize  or  completely 
eliminate  the  problems  associated  with  the  printing,  shipping,  storage,  and  deterioration  of  paper.  Even 
more  significant  are  the  additional  benefits  not  possible  with  paper.  These  include  the  capability  to 
support: 


•  Interactive  use,  which  guides  the  user  through  maintenance  procedures 

•  Adapt  procedures  in  real  time  according  to  current  fault  indications 

•  Maintain  test  procedure  variations  according  to  the  configuration  of  the  System-Under-Test 

•  Inclusion  of  user  notes  and  comments  into  procedures 

•  Capture  of  information  produced  during  maintenance  actions 
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•  Self-learning,  based  on  knowledge  base  built  from  data  capture 

•  Adaptive  training  based  on  actual  procedures,  and  suited  for  Just-In-Time  and  distance 
training 

However,  for  users  that  are  accustomed  to  working  with  paper,  not  having  a  physical  document  may  be 
awkward  for  a  period  of  time.  The  system  implementation  must  account  for  this,  and  must  have  enough 
“redeeming  qualities”  to  encourage  the  user  to  get  beyond  this  stage. 


EDTIS  TECHNICAL  DOCUMENTATION  ACCESSIBILITY 
DIGITIZATION  OF  TECHNICAL  INFORMATION 

The  EDTIS  program  examines  the  content  of  several  Technical  Orders  used  in  the  maintenance  of  various 
USAF  systems.  The  TOs,  which  contain  step-by-step  maintenance  procedures,  diagrams,  and  background 
information,  are  structured  as  a  compromise  between  the  way  they  are  expected  to  be  used,  and  the  reality 
of  being  published  in  a  paper  document  format,  namely  a  series  of  sequential  pages,  bound  together. 

It  is  inevitable  that  many  procedures  will  have  several  alternative  variations.  Such  variations  come  about 
from  maintaining  similar,  but  not  identical  aircraft;  different  revisions  of  hardware  and  software  of  the 
system  being  maintained;  and  a  host  of  other  reasons.  In  this  scenario,  variations  to  fundamental 
procedures  are  awkward  to  script  into  a  paper  document.  The  result  is  that  each  variation  of  the  basic 
procedure  is  reproduced  in  the  text  repeatedly,  or  a  core  procedure  is  presented,  with  annotations 
identifying  the  steps  involved  that  "tailor"  the  procedure  to  the  user's  particular  situation.  The  first 
alternative  generates  large  documents  that  are  difficult  to  maintain,  since  complex  procedures  are  nearly 
duplicated  throughout  the  document.  The  second  puts  the  burden  on  the  user  to  correctly  execute  the 
procedure  while  minding  the  annotations  to  be  sure  that  each  step  of  the  procedure  is  the  correct  one  for 
his/her  configuration. 

In  preparing  to  create  an  electronic  document  (IETM),  it  is  important  to  take  advantage  of  the  ability  for 
the  document  to  contain  information  that  enables  the  document  viewer  to  adapt  the  presentation  to  the 
user  according  to  the  particular  situation.  For  example,  the  procedure  would  initially  query  the  user  to  the 
configuration  of  the  hardware  and  software.  Subsequent  maintenance  steps  would  be  presented  to  the  user 
only  if  applicable  to  the  user's  system  configuration. 

Since  IETMs  are  interactive,  they  can  guide  the  user  through  the  repair  process.  They  can,  depending  on 
the  effort  committed  to  their  authoring,  automatically  identify  the  precise  repair  procedure  indicated  by 
the  system's  symptoms  and/or  diagnosed  faults.  They  can  display  the  correct,  pertinent  diagrams  and 
schematics,  as  well  as  parts  and  interchangeability  listings.  Eliminated  is  the  need  to  manually  search 
through  volumes  of  paper  documents  or  CD-ROMs,  which  are  often  outdated,  lost,  or  damaged.  IETMs 
can  harness  the  power  of  self-learning.  IETMs  constructed  in  this  way  capture  data  from  each 
maintenance  action,  continuously  building  a  knowledge  base  that  becomes  smarter  with  each  use. 

This  is  one  example  of  the  power  of  electronic  documentation.  Other  areas  made  possible  include: 


•  Adaptive  training,  where  the  procedures  are  used  for  training  purposes,  and  are  able  to  adapt  to  the 
particular  training  situation,  and  even  "learn"  what  areas  trainees  have  the  most  success  and  the  most 
trouble  with,  to  help  improve  the  training  for  the  next  student. 

•  The  diagnostic  procedures  can  be  enhanced  to  do  much  more  without  causing  additional  burden  on 
the  user,  since  much  more  logic  can  be  included  "behind  the  scenes"  of  the  presentation  of  the 
procedure  to  the  user.  Additional  logic  can  make  use  of  historical  maintenance  and  failure  data, 
calibration  results,  schematic  analysis,  etc. 
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REMOTE  ACCESS  THROUGH  SATELLITE 


The  use  of  satellite  technology  to  provide  the  infrastructure  to  use  electronic  documents  provides 
significant  capability,  several  of  which  are  not  available  through  other  means,  including: 

•  Virtually  instantaneous  worldwide  data  delivery  and  collection 

•  Assessment  of  system  damage  incurred  during  battle 

•  Visibility  into  asset  management  and  system  configurations 

•  Integration  of  remote  sites  into  a  cohesive  system 

•  Databases  kept  current  and  available 

•  Central  configuration  management 


PORTABLE  MAINTENANCE  AIDS 

In  order  to  receive  the  benefits  of  electronic  documents,  they  must  be  viewed  on  some  form  of  an 
electronic  display.  For  the  aircraft  maintainer,  a  Portable  Maintenance  Aide  (PM A)  is  used.  The  PMA  is 
linked  to  a  local  server,  either  by  radio  link  or  through  a  disk-docking  system.  The  particulars  of  each 
installation  determine  which  method  of  linking  is  used.  The  PMA  can  also  be  designed  with  the 
capability  of  interfacing  with  a  bus  of  the  system  under  test  for  even  more  powerful  diagnostic  capability. 

EDTIS  will  analyze  various  commercially  available  devices  for  suitability.  Several  mggidized  laptop 
computers  will  be  evaluated  for  various  features,  including  screen  size  and  quality,  reaction  to  heat,  cold, 
and  sunlight,  battery  life,  processing  power,  cost,  and  other  features  important  to  users. 


POTENTIAL  SAVINGS  OF  EDTIS 

It  is  evident  that  the  technology  demonstrated  by  the  AAMRSSS  and  EDTIS  programs  can  make  a 
significant  impact  to  the  way  that  aircraft  maintenance  is  performed.  Some  of  the  changes  are  so 
significant  that  it  is  difficult  to  quantify  without  application  to  a  particular  implementation.  That  is,  any 
organization  that  implements  the  technology  presented  here  will  adapt  their  implementation  according  to 
their  requirements.  The  individual  installations  will  vary  widely,  as  will  the  cost  savings.  The 
AAMRSSS  and  EDTIS  demonstrations  provide  proof  of  concept  and  the  collection  of  user  feedback  for 
design  improvements,  and  include  qualitative  considerations  for  cost  savings.  As  the  technology  is 
implemented  in  a  variety  of  situations,  data  will  become  available  indicating  expected  savings. 

It  is  safe  to  say  that  the  cost  of  incorrect  maintenance  actions  due  to  outdated  materials  or  misunderstood 
configuration-dependent  procedures  can  be  tremendous,  even  life  threatening.  It  is  from  this  perspective 
that  the  above  programs  have  focused  on  the  technical  aspects,  since,  virtually  by  definition,  if  the 
technology  can  reduce  incorrect  maintenance  actions,  the  savings  will  be  significant  and  worthwhile. 


SUMMARY  AND  CONCLUSIONS 

The  following  is  a  list  of  several  advantages  of  an  EDTIS  system: 

•  Eliminate  distribution  of  paper  Technical  Orders  and  associated  configuration 
management  costs 

•  Eliminate  distribution  delays 

•  Assuring  availability  of  the  most  current  technical  data 

•  Eliminate  lost  TOs  and  change  pages 
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•  Enable  rapid  deployment  of  Aircraft  support  infrastructure 

•  Eliminate  hundreds  of  pounds  (conservative  figure)  of  paper 

•  Increase  aircraft  payload 

•  Reduced  Mean  Time  To  Repair  via  improved  data  accuracy 

•  Increase  combat  capability  by  reducing  aircraft  down  time 

•  Decrease  repair  cycle  costs  by  reducing  false  LRU  pulls 

•  Reduce  spares  requirement  by  reducing  false  pulls 

•  Reduced  manpower  skill  level  requirements  via  “smart”  IETMs 

•  New  capabilities  possible  -  maintenance  history,  fault  diagnosis,  automated 
parts  ordering,  etc. 

•  Commercial  Satellite  redundancy  reduces  resource  dependence  vulnerability 

•  On-line  Expert  assistance  feasible  to  enhance  2-level  maintenance  policy 

The  best  summary  of  this  paper  is  to  contrast  the  above  list  with  common  situations  that  weapon  system 
maintainers  face: 

•  Dependency  on  distribution  of  paper  Technical  Orders  from  multiple  sources 
with  non-standard  configuration  management  of  each  source 

•  Frequent  distribution  delays 

•  Non-availability  of  the  most  current  technical  data 

•  Lost  TOs  and  change  pages,  hard  copies  deteriorate  after  repeated  usage 

•  Delayed  deployment  of  Aircraft  support  infrastructure 

•  Required  to  handle  and  move  hundreds  of  pounds  (conservative  figure)  of 
paper 

•  Decreased  aircraft  payload 

•  Mean  Time  To  Repair  increased 

•  Decreased  combat  capability  due  to  increased  aircraft  down  time 

•  Increased  repair  cycle  costs  because  of  increased  false  LRU  pulls 

•  More  spares  requirement  because  increased  false  pulls 

•  Higher  manpower  skill  level  requirements  because  of  untimely  technical  data 

•  Reduced  access  to  new  capabilities,  because  of  the  non-standard  distribution  of 
technical  data 

•  Inherent  resource  dependence  vulnerability 

•  On-line  Expert  assistance  difficult  to  enhance 
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In  conclusion,  the  work  performed  by  System  2000,  AAMRSSS,  and  EDTIS  supports  a  common  sense 
approach  that  weapon  system  crew  chiefs  historically  stated,  defined,  and  designed.  These  crew  chiefs 
intimate  knowledge  of  their  weapon  systems  and  the  processes  that  maintain  them  give  rich  insight  into 
the  hidden  costs  of  the  system  life-cycle,  those  of  operation  and  maintenance. 

A  key  resource  required  for  operational  and  maintenance  support  is  the  timely  access  of  accurate  technical 
documentation.  The  EDTIS  program  not  only  provides  this  useful  technical  information;  it  also  enables 
addition  of  information  technologies. 
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The  following  is  a  list  of  several  advantages  of  an  EDTIS  system: 

•  Eliminate  distribution  of  paper  Technical  Orders  and  associated  configuration 
management  costs 

•  Eliminate  distribution  delays 

•  Assuring  availability  of  the  most  current  technical  data 

•  Eliminate  lost  TOs  and  change  pages 

•  Enable  rapid  deployment  of  Aircraft  support  infrastructure 

•  Eliminate  hundreds  of  pounds  (conservative  figure)  of  paper 

•  Increase  aircraft  payload 

•  Reduced  Mean  Time  To  Repair  via  improved  data  accuracy 

•  Increase  combat  capability  by  reducing  aircraft  down  time 

•  Decrease  repair  cycle  costs  by  reducing  false  LRU  pulls 

•  Reduce  spares  requirement  by  reducing  false  pulls 

•  Reduced  manpower  skill  level  requirements  via  “smart”  IETMs 

•  New  capabilities  possible  -  maintenance  history,  fault  diagnosis,  automated 
parts  ordering,  etc. 

•  Commercial  Satellite  redundancy  reduces  resource  dependence  vulnerability 

•  On-line  Expert  assistance  feasible  to  enhance  2-level  maintenance  policy 


The  best  summary  of  this  paper  is  to  contrast  the  above  list  with  common  situations  that  weapon  system 
maintainers  face: 


•  Dependency  on  distribution  of  paper  Technical  Orders  from  multiple  sources 
with  non-standard  configuration  management  of  each  source 

•  Frequent  distribution  delays 

•  Non-availability  of  the  most  current  technical  data 

•  Lost  TOs  and  change  pages,  hard  copies  deteriorate  after  repeated  usage 

•  Delayed  deployment  of  Aircraft  support  infrastructure 

•  Required  to  handle  and  move  hundreds  of  pounds  (conservative  figure)  of 
paper 

•  Decreased  aircraft  payload 

•  Mean  Time  To  Repair  increased 

•  Decreased  combat  capability  due  to  increased  aircraft  down  time 

•  Increased  repair  cycle  costs  because  of  increased  false  LRU  pulls 

•  More  spares  requirement  because  increased  false  pulls 

•  Higher  manpower  skill  level  requirements  because  of  untimely  technical  data 

•  Reduced  access  to  new  capabilities,  because  of  the  non-standard  distribution 
of  technical  data 

•  Inherent  resource  dependence  vulnerability 

•  On-line  Expert  assistance  difficult  to  enhance 
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ABSTRACT 

The  U.S.  Army  Edgewood  Chemical  Biological  Center  (ECBC)  and  its  parent  command  are 
committed  to  the  implementation  of  simulation-based  acquisition  and  training  techniques. 
Their  value  has  been  demonstrated  repeatedly  by  many  organizations  and  in  countless 
situations  representing  all  aspects  of  the  product  life  cycle,  including  combat  development, 
material  development,  manufacturing,  training,  and  employment.  Models  and  simulations 
have  become  practical  tools  that  routinely  replace  laboratory  experiments,  field  activities,  and 
training  exercises  while  reducing  cost  and  improving  safety.  They  could  be  particularly 
effective  for  smoke  and  obscurant  scenarios,  which  cany  significant  environmental  clearance 
costs  and  additional  safety  considerations.  Numerous  models  have  been  developed  to  simulate 
smoke  and  obscurant  systems,  but  most  of  these  have  focused  on  detailed  scientific  and 
engineering  issues,  such  as  cloud  physics  and  electro-optical  performance.  Although  several 
attempts  have  been  made  to  integrate  these  models  into  constructive  and  distributed 
interactive  simulations,  no  smoke  and  obscurant  model  has  emerged  that  supports 
opertational  level  activities.  This  is  a  significant  shortcoming  that  hampers  both  training  and 
acquisition.  This  paper  reviews  the  state  of  smoke  and  obscurant  models  and  illustrates  how 
existing  simulations  have  been  used  to  support  acquisition  and  training.  It  also  identifies 
requirements  for  operational-level  tools  and  establish  a  framework  for  their  development. 


1.  MODELING  AND  SIMULATION  TRENDS 

Modeling  and  simulation  (M&S)  has  become  an  essential  technology  that  is  influencing  a 
growing  number  of  mission-critical  activities.  Organizations  within  DoD  are  increasingly  using 
it  for  operational  planning;  research,  development,  and  acquisition;  test  and  evaluation; 
training  and  mission  rehearsal;  and,  doctrine  development.  This  growth  is  being  fueled  by 
budgetary  constraints,  environmental  concerns,  and  technological  advances,  which  reduce  the 
cost  of  complex  computer  systems  while  increasing  their  capabilities. 

Historically,  most  M&S  activities  have  been  conducted  in  vertical  stovepipes  within  application 
domains  (figure  1)  and  there  has  been  little  horizontal  integration.  The  constructive  wargames 
and  virtual  simulations  used  for  training  have  seldom  been  linked,  for  example,  to  engineering- 
level  simulations  or  the  physical  models  they  use. 
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Figure  1.  DoD  modeling  and  simulation  domains. 


The  computational  burden  imposed  by  high  fidelity  models  has  often  limited  their  utility 
beyond  the  application  domain  for  which  they  were  developed.  This  is  certainly  true  for  smoke 
and  obscurant  models,  which  have  little  presence  in  the  preeminent  simulation  environments. 
Until  recently,  horizontal  integration  was  infeasible  due  to  limitations  imposed  by  hardware, 
software,  and  design  methodologies.  This  situation  is  changing,  however,  as  technological 
developments  increase  computer  system  performance,  simplify  connectivity,  reduce  cost, 
improve  usability,  enhance  the  development  process,  and  promote  software  reuse.  These 
factors  are  reshaping  the  nature  of  DoD  models  and  driving  a  paradigm  shift  toward  a  more 
flexible  and  efficient  simulation  environment  (figure  2). 
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Figure  2.  Modeling  and  simulation  trends. 


The  Defense  Modeling  and  Simulation  Office  (DMSO)  has  capitalized  on  these  trends  to 
produce  a  High  Level  Architecture  (HLA)1  that  unifies  all  M&S  domains  under  a  single  technical 
framework.  Future  DoD  M&S  systems  will  be  required  to  comply  with  the  HLA,  which  specifies 
a  design  philosophy,  imposes  documentation  requirements,  and  provides  a  common  cross¬ 
platform  run  time  infrastructure  (RTI).  The  HLA  will  facilitate  linkages  between  models  and 
promote  software  reuse  across  all  M&S  domains.  We  are  entering  a  period  where  software, 
that  was  developed  for  one  specific  purpose,  can  be  used  without  modification  in  many 
different  applications.  This  will  enable  engineering-level,  constructive  wargames,  and  virtual 
simulations  to  use  physical  models  to  increase  their  fidelity  with  real  world  phenomena. 


2.  SMOKE  AND  OBSCURANT  MODELS 

Several  physical  models  have  been  developed  to  simulate  the  production,  transport,  and 
diffusion  of  battlefield  obscurants  and  assess  their  effect  on  tactical  sensors.  The  U.S.  Army 
Research  Laboratory  (ARL)  has  been  a  major  contributor  and  it  maintains  two  smoke  and 
obscurant  models  in  its  Electro-Optical  Systems  Atmospheric  Effects  Library2’3.  GRNADE4 
simulates  multiple-round  salvos  of  tube-launched  grenades  (L8A1  and  M76)  and  is  used  for 


self-screening  analysis.  The  Combined  Obscuration  Model  for  Battlefield-Induced 
Contaminants  (COMBIC)5-6  is  more  comprehensive  and  can  simulate:  high  explosive  and 
vehicular  dust;  phosphorus  and  hexachloroethane  munitions;  diesel  fuel,  oil,  and  rubber 
fires;  generator-disseminated  oils;  other  screening  aerosols,  and  user-defined  sources. 

COMBIC  has  been  used  in  numerous,  diverse  applications  and  is  arguably  the  dominant  model 
in  this  field.  It  operates  on  level  terrain  and  only  considers  a  horizontally  homogeneous  wind 
(figure  3).  These  limitations  led  ARL  to  develop  a  derivative  model,  the  Simulation  of  Aerosol 
Behavior  in  Realistic  Environments  (SABRE)7,  that  can  use  a  terrain-dependent  wind  field. 
SABRE  was  an  EOSAEL  module  for  some  time,  but  is  no  longer  supported  by  ARL  and  has 
been  withdrawn  from  the  library,  leaving  it  without  a  smoke  and  obscurant  model  that  handles 
non-uniform  wind  and  terrain. 
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Figure  3.  Lineage  and  primary  characteristics  of  COMBIC  and  its  derivatives. 


The  Joint  Project  Office  for  Smoke,  Obscurants,  and  Special  Technologies  Counter-measures 
(JPO-SOSTC),  Naval  Surface  Warfare  Center  (NSWC),  ECBC,  and  OptiMetrics,  Inc.  (OMI)  have 
enhanced  SABRE  to  create  the  Transport,  Diffusion,  and  Radiance  (TDR)  model8.  It  has  been 
integrated  into  several  applications  and  can  operate  in  a  stand-alone  mode  on  numerous 
computing  platforms. 

COMBIC  and  TDR  were  originally  developed  in  the  mid  1980s  to  the  early  1990s  using 
prevailing  techniques.  They  are  large,  monolithic  programs  that  are  written  in  FORTRAN  using 
extremely  unstructured  code.  Their  software  components  make  extensive  use  of  global 
variables  and  are,  therefore,  highly  interdependent.  In  short,  they  are  not  well  suited  for  use  in 
a  simulation  environment  that  is  increasingly  distributed  and  object-oriented. 

Both  models  describe  clouds  as  a  collection  of  one  to  five  subclouds,  which  can  be  either 
Gaussian  puffs  or  plumes.  When  a  source  is  activated,  subcloud  states  are  computed  at 
discrete  downwind  distances  and  the  results  are  saved  in  a  history  file.  All  predictions  are 
made  using  the  atmospheric  conditions  that  existed  at  the  time  of  source  activation.  Although 
this  approach  is  computationally  efficient,  it  is  not  responsive  to  changes  in  atmospheric 
conditions  that  might  occur  during  the  cloud’s  lifetime.  It  also  requires  a  large  amount  of  data 
to  be  maintained  (and  possibly  transferred)  for  subsequent  calculations. 


Because  they  were  developed  several  years  ago,  COMBIC  and  TDR  only  simulate  sources  and 
obscurants  that  were  available  (primarily  to  U.S.  forces)  at  that  time.  The  models  have  not 
been  updated  significantly  to  include  equipment,  munitions,  or  materials  that  have  been 
fielded  in  recent  years  or  are  currently  under  development  by  the  U.S.,  our  allies,  and  potential 
adversaries.  Both  models  enable  the  user  to  specify  source  and  obscurant  characteristics 
through  data  inputs,  but  this  requires  an  intimate  knowledge  of  the  material  and  model 
properties. 

Neither  of  these  programs  model  vehicles  or  vehicular  components.  They  have  no  awareness  of 
specific  vehicle  types  nor  the  location  and  orientation  of  smoke  generation  equipment  on  those 
vehicles.  Consequently,  COMBIC  and  TDR  could  not  be  used  by  themselves  to  examine 
operational  usage  where  component  placement  is  an  issue.  This  limitation  is  aggravated  by 
their  inability  to  accept  unscripted  inputs.  The  models  cannot  be  used  without  augmentation 
to  respond  to  ad  hoc  smoke  events  that  might  be  generated  randomly,  by  a  constructive 
wargame  under  player  control,  or  by  networked  simulators  in  a  virtual  exercise.  In  addition 
some  deficiencies  have  been  noted  in  their  predictive  algorithms.  Most  notably,  COMBIC  does 
not  accurately  model  evaporative  losses  from  disseminated  oils  as  a  function  of  temperature9. 
This  affects  the  predicted  quantity  of  suspended  liquid  that  is  actually  available  for  producing 
screening  effects,  a  critical  factor  in  some  applications  where  oil  smokes  are  employed. 


3.  SMOKE  SYSTEM  PERFORMANCE  MODEL 

The  Smoke  System  Performance  Model  (SSPM)10  was  developed  by  ECBC  and  OMI  to  eliminate 
many  of  the  limitations  noted  above.  It  is  a  collection  of  C++  classes  that  model  the  essential 
elements  of  smoke  and  obscurant  systems.  The  classes  can  be  integrated  with  engineering- 
level  models,  constructive  wargames,  and  virtual  simulations  to  enhance  their  ability  to 
simulate  battlefield  obscuration. 

SSPM  models  relevant  items,  such  as  vehicles,  components,  clouds,  obscurant  materials,  and 
vehicular  grenades.  Each  class  encapsulates  the  essential  technical  characteristics  of  the  item 
it  represents,  as  they  relate  to  smoke  and  obscurant  production,  and  provides  default 
functionality.  The  default  behaviors  vary  in  sophistication  and  can  be  overridden  if  enhanced 
functionality  is  required.  The  notional  default  behavior  of  SSPM  clouds  can  be  enhanced  by 
using  a  smoke  and  obscurant  model,  such  as  COMBIC  or  TDR,  to  simulate  cloud  production, 
transport,  and  diffusion.  When  this  is  done,  SSPM  acts  as  a  preprocessor  by  simulating 
operations  at  a  higher  level  and  directing  the  smoke  and  obscurant  models  to  place  clouds  with 
specified  characteristics  at  designated  times  and  places. 

SSPM  is  limited  only  by  the  scope  of  the  systems  it  currently  models.  The  latest  version  can 
simulate  thirteen  vehicles,  seven  vehicle-launched  grenades,  vehicle  engine  exhaust  smoke 
systems,  and  two  smoke  generators.  It  does  not  yet  model  smoke  pots  or  artillery,  mortar, 
rocket,  and  aircraft-delivered  obscurants.  Only  one  of  the  vehicles  and  one  of  the  grenades  are 
foreign  systems. 


4.  ENGINEERING  LEVEL  MODELS 

SSPM  has  been  linked  to  COMBIC  in  the  Cloud  Density  Visualization  Utility  (CDVis)10,  an 
engineering-level  model  that  presents  a  graphical  representation  of  simulated  clouds  (figure  4). 
CDVis  uses  SSPM  to  execute  complex  obscuration  scenarios,  COMBIC  Phase  I  to  predict  cloud 
histories,  and  COMBIC  Phase  II  to  compute  concentration  path  lengths  along  specified  lines-of- 
sight.  The  concentration  path  lengths  or  their  corresponding  transmittance  values  are  then 
presented  as  false  color  images,  enabling  the  user  to  perceive  the  clouds  in  three  dimensions  as 
a  function  of  time. 


Figure  4.  CDVis  displaying  cloud  density  images  for  the  front, 
side,  top,  and  radial  views  of  a  simulated  obscuration  event. 

SSPM  has  also  been  linked  to  COMBIC  in  a  battle  management  system  (BMS)  for  chemical  staff 
officers  that  will  be  used  to  evaluate  smoke  and  obscurant  plans  (figure  5).  The  BMS  is  similar 
to  CDVis  in  its  use  of  SSPM  and  COMBIC,  but  it  superimposes  a  birds  eye  view  of  the 
simulated  clouds  on  a  tactical  land  map.  The  BMS  also  predicts  sensor  effectiveness  on  a 
horizontal  plane  from  a  given  location  at  a  designated  time  and  distance  above  ground  level. 
Effectiveness  is  presented  as  a  radar  plot  that  uses  green,  amber,  and  red  to  depict  regions  of 
increasing  cloud  density  in  accordance  with  specified  transmission  thresholds. 


Figure  5.  Chemical  Staff  Officer’s  BMS  displaying  a  sensor  effectiveness  plot 
superimposed  on  a  cloud  density  image  of  a  simulated  obscuration  event. 


This  program  demonstrates  the  power  of  object-oriented  methodologies,  which  foster  software 
reuse  by  encapsulating  functionality  and  enabling  components  to  be  assembled  into  new  and 
different  applications.  Most  of  the  smoke-related  code  in  BMS  is  identical  to  that  used  in 
CDVis.  The  only  difference  is  some  minor  additions  that  were  applied  to  support  its  unique 
display  requirements.  Also,  the  BMS  graphical  user  interface  is  written  in  Java  while  SSPM 
and  its  CDVis  extensions  are  written  in  C++  and  the  extended  cloud  class  places  an  object 
wrapper  around  COMBIC’s  FORTRAN  code.  The  object-oriented  technology  enables  these 
disparate  components  to  be  drawn  together  with  relative  ease  to  create  a  new  and  useful 
application. 


5.  CONSTRUCTIVE  WARGAMES 

JPO-SOSTC,  NSWC,  the  USMC  Systems  Command,  and  OMI  have  integrated  TDR  into  a  many- 
on-many  Sensor/ Obscurant  Engagement  Simulation  (SOES).  It  has  been  used  by  combat  and 
material  developers  to  assess  tactical  concepts  for  smoke  employment  in  littoral  operations 
(figure  6).  SOES  uses  physical  models  to  simulate  sensor  performance  and  TDR  Phase  I  to 
produce  terrain-sensitive  smoke  clouds.  Intervisibility  issues  are  addressed  using  digital 
terrain  elevation  data  and  TDR  Phase  II. 


SOES  uses  TDR  as  an  independent  executable  program  without  augmentation,  so  it  is  limited 
to  the  smoke  sources  that  TDR  inherently  supports.  These  sources  are  positioned  and 
activated  in  accordance  with  an  scripted  scenario. 


Figure  6.  A  SOES  display  depicting  terrain  sensitive  TDR-generated  clouds. 


The  US  Army  Training  and  Doctrine  Command  has  integrated  COMBIC  into  CASTFOREM,  a 
stochastic  force-on-force  model  that  is  used  to  assess  combat  system  performance11.  It  is  the 
Army's  primary  tool  for  conducting  formal  Analysis  of  Alternatives  (AoA).  CASTFOREM  uses 
COMBIC  to  predict  transmissivity  through  obscurant  clouds,  which  have  been  produced  by 
simulated  combat  events.  When  activated,  COMBIC  is  employed  throughout  the  gaming 
exercise,  but  the  smoke  effectiveness  assessments  are  limited  to  discrete  engagement  segments 
and  only  affect  certain  operations,  such  as  laser  range  finding  and  missile  flyout.  During  laser 
operations,  CASTFOREM  does  consider  the  affect  of  obscurants  on  a  laser  beam  and  will 
attenuate  the  returning  signal  appropriately.  During  guided  missile  flyouts,  CASTFOREM 
periodically  uses  COMBIC  to  determine  if  obscurants  have  cause  the  missile  to  break  lock. 

Obscurant  usage  places  a  large  computational  burden  on  CASTFOREM  and  can  significantly 
increase  run  times.  Because  COMBIC  is  used  in  its  native  form,  CASTFOREM  can  only  use 
standard  sources.  And,  because  there  is  no  direct  linkage  to  operational  entities,  such  as 
vehicles,  artillery  units,  and  aircraft,  smoke  events  must  be  manually  inserted  by  exercise 
controllers. 


6.  VIRTUAL  SIMULATIONS 

In  recent  years,  DoD  has  invested  heavily  in  distributed  interactive  simulation  (DIS) 
technologies  that  enable  manned  and  unmanned  simulators  to  interact  on  a  common  virtual 
battlefield.  DIS  simulations  have  been  used  extensively  for  small  unit  training  and  are 
increasingly  used  in  other  applications,  including  simulation  based  acquisition.  Interactions 
are  facilitated  through  the  exchange  of  messages  using  well  defined  protocols.  The  DIS 
standard  provides  for  the  transmission  of  some  smoke  information,  enabling  one  battlefield 
entity  to  produce  a  smoke  event  and  report  its  state  to  all  other  networked  simulations. 

The  Modular  Semi-Automated  Forces  (ModSAF)  program  is  used  extensively  in  DIS  applications 
to  populate  the  virtual  world  with  battlefield  entities,  such  as  aircraft  and  armored  vehicles. 
These  entities  behave  in  an  intelligent  manner  and  are  indistinguishable  from  their  manned 
counterparts. 

The  use  of  smoke  and  obscurants  by  ModSAF  entities  is  notional.  Certain  vehicle  types  have  a 
limited  ability  to  launch  salvos  of  self-protective  grenades  and  artillery/ mortar  projectiles.  No 
other  smoke  sources  are  supported.  ModSAF  uses  pre-computed  COMBIC  history  files  to 
instantiate  obscurant  clouds,  but  these  clouds  are  limited  to  one  subcloud  each,  which 
severely  restricts  their  fidelity.  ModSAF  does  consider  obscurant  effects  on  entity 
engagements,  but  few  other  DIS  applications  do.  The  scene  generators  on  most  manned  DIS 
simulators  cannot  render  smoke  clouds  (with  the  exception  of  some  trailing  effects  attached  to 
some  entities)  and  they  do  not  affect  crew  vision  whatsoever. 

The  Close  Combat  Tactical  Trainer  (CCTT)  is  a  family  of  networked  simulations  that  is  used  to 
train  armor,  cavalry,  and  mechanized  infantry  platoons  in  the  performance  of  collective  tasks. 
CCTT  includes  manned  simulators  for  numerous  combat  vehicles  and  a  semi-automated  forces 
program  (similar  to  ModSAF)  that  can  control  a  wide  variety  of  friendly  or  opposing  units. 
CCTT  uses  a  variant  of  the  DIS  standard  protocols  to  establish  and  maintain  the  synthetic 
environment. 

CCTT  has  an  extremely  limited  capability  for  simulating  smoke  events  and  only  supports  three 
obscurant  types:  hydrochloric  acid,  red  phosphorus,  and  white  phosphorus.  Manned  CCTT 
simulators  do  render  smoke  clouds  using  an  animation  technique  that  can  vary  transmittance 
in  accordance  with  obscurant  characteristics.  This  does  affect  crew  visibility  which  can 
influence  combat  operations.  Other  obscurant  effects  are  not  supported. 


7.  FUTURE  REQUIREMENTS 


Smoke  and  obscurants  do  affect  battlefield  sensors  and  those  effects  can  influence  combat 
operations.  It  is  important  for  obscurant  systems  to  be  reasonably  represented  in  models  and 
simulations  so  that  their  influence  can  be  properly  assessed.  The  capabilities  and  limitations 
of  U.S.,  allied,  and  opposing  forces  must  all  be  considered.  Smoke  and  obscurant  modeling 
should  not  be  done  for  its  own  sake,  but  it  must  be  done  to  insure  that  soldiers  are  properly 
trained  and  equipped  to  operate  on  the  dirty  battlefield.  It  is  incumbent  upon  the  smoke  arid 
obscurant  community  to  make  sure  that  occurs. 

The  survey  presented  above  describes  the  current  state  of  smoke  and  obscurant  modeling.  It  is 
by  no  means  comprehensive,  but  does  highlight  strengths  and  weaknesses  in  several 
application  domains.  The  survey  illustrates  that  smoke  and  obscurant  modelers  have  done 
extremely  good  work  where  it  was  feasible  to  do  so.  They  have  developed  excellent  physical 
models  that  reasonably  simulate  the  growth,  transport,  and  diffusion  of  obscurant  clouds  while 
striking  a  balance  between  fidelity  requirements  and  computational  constraints.  And,  the 
physical  models  have  been  used  in  numerous  applications  to  perform  useful  training  and 
analytical  functions.  The  survey  also  illustrates,  however,  that  smoke  and  obscurant  modelers 
have  failed  to  accomplish  what  heretofore  was  infeasible  to  do.  Despite  all  good  intentions  and 
a  lot  of  intense  effort,  they  have  not  managed  to  insert  a  significant  amount  of  smoke  and 
obscurant  play  into  the  tactical  simulations  that  are  routinely  used  for  training  and 
simulation-based  acquisition.  Given  technological  limitations,  it  was  just  too  difficult  to 
achieve.  That  situation  is  changing. 

Recent  advancements  in  hardware  and  software  technologies  are  enabling  simulations  to  model 
physical  phenomena  with  increasing  fidelity.  The  emergence  of  new  design  methodologies  are 
facilitating  the  development  of  true  software  components  that  can  readily  be  used  in  diverse 
computing  environments.  This  is  an  excellent  time  to  begin  the  development  of  smoke  and 
obscurant  components  for  the  simulation  community  at  large. 

These  components  must  be  comprehensive,  flexible,  authoritative,  efficient,  self-contained,  and 
HLA  compliant,  as  described  below: 

Comprehensive.  Collectively,  the  simulation  components  should  model  all  smoke  and 
obscurant  systems  that  U.S.  forces  are  likely  to  use  or  encounter  on  any  future  battlefield. 

Flexible.  For  maximum  applicability  across  all  M&S  domains,  each  component  (or 
variation  thereof)  must  be  able  to  operate  at  several  resolutions.  High  fidelity  simulations 
will  need  high  fidelity  smoke  representations  while  low  fidelity  simulations  will  need  the 
opposite.  Also,  cloud  behavior  must  be  4-dimensional  (i.e.,  sensitive  to  spatial  and 
temporal  variations  in  atmospheric  conditions,  if  they  exist). 

Authoritative.  Each  component  must  simulate  the  item  it  represents  with  sufficient 
fidelity  to  satisfy  the  smoke  and  obscurant  community  at  all  possible  resolutions. 

Efficient.  Smoke  and  obscurant  modeling  is  computationally  intensive  and  that  burden 
has  limited  its  utility  in  many  applications.  The  simulation  components  must  employ  more 
efficient  algorithms  than  those  used  today,  particularly  for  modeling  cloud  behavior  and 
obscurant  effects.  The  use  of  neural  nets  and  related  technologies  should  be  investigated 
to  determine  if  they  can  enhance  performance  without  degrading  fidelity.  Also,  data 
exchange  requirements  among  networked  simulators  must  be  minimized 

Self-contained.  Developers  will  not  use  the  components  if  it  is  difficult  to  integrate  them 
into  applications.  Consequently,  they  must  be  designed  using  accepted  object-oriented 


techniques  which  require  they  encapsulate  all  characteristics  and  behaviors  and  expose  a 
well-defined  interface. 

HLA  compliant.  The  simulation  components  must  be  developed  in  accordance  with  the 
HLA  specification.  They  must  be  fully  documented  with  federation  object  models  (FOM) 
and/or  simulation  object  models  (SOM),  as  appropriate.  The  components  must  employ  the 
simulation  support  services  provided  by  the  RTI. 
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Abstract 

Assessing  the  impact  of  obscurants  on  performance  is  a  very  complex  issue.  Atmospheric  propagation 
through  obscurants  can  effect  acquisition  by  the  U.S.  missiles.  This  report  describes  a  technique,  as  well 
as  models  used  to  simulate  and  analyze  battlefield  scenes  in  the  wavelength  of  interest  using  the 
Combined  Obscuration  Model  for  Battlefield  Induced  Contaminants  (COMBIC)  model.  Most  analysis  of 
obscurant  effects  on  battlefield  sensors  have  focused  on  using  a  single  band-averaged  mass  extinction 
coefficient  to  represent  the  obscurant’s  ability  to  degrade  the  Line  of  Sight  (LOS).  This  mass  extinction 
coefficient  when  combined  with  the  Concentration  Length  (CL)  yields  a  single  number  for  the 
transmittance  over  the  wavelength  band.  The  extinction  for  several  wavelength  bands  are  modeled  in 
COMBIC.  Project  managers  have  expressed  an  interest  in  the  spectral  attenuation  (the  variation  of  the 
attenuation  due  to  variation  in  the  mass  extinction  coefficient  sometimes  referred  to  as  “complex” 
attenuation  by  the  user)  over  the  band-pass  specific  to  their  sensor.  An  aerosol  code  has  been  used  to 
model  the  variation  of  mass  extinction  coefficient  with  wavelength.  The  COMBIC  CL  data  can  then  be 
combined  with  the  wavelength-dependent  extinction  coefficient  to  determine  the  spectral  attenuation  over 
the  specific  band-pass  for  the  sensor.  This  represents  a  significant  improvement  in  the  use  of  COMBIC 
over  using  a  single  number  for  attenuation  to  represent  a  “canned  band-pass”.  The  spectral  attenuation 
is  used  in  this  report  to  describe  the  variation  in  apparent  emissivities  for  some  naturally  occurring 
materials.  Analysis  shows  that  the  range  of  the  transmitted  emissivity  for  a  tree  leaf  at  8  -  14  microns 
through  White  Phosphorus  smoke  at  moderate  CL  values  is  .28.  The  range  in  emissivity  for  tree  leaf 
without  smoke  is  .02.  The  aerosol  code  is  used  to  compare  the  band-averaged  WP  mass  extinction 
coefficient  with  COMBIC  values.  Excellent  agreement  is  obtained  with  a  root-mean- square  of  less  than 
7%  for  the  visual  and  1.54  microns.  Therefore,  the  aerosol  code  is  used  to  compute  the  coefficients  for 
the  extinction  equation  used  by  COMBIC  to  compute  variation  of  extinction  with  relative  humidity  for  at 
.3  microns  and  1.54  microns. 

1.  Introduction 

The  Broadband  Integrated  Transmittances  (BITS)  model  was  developed  by  the  (then)  U.S.  Army 
Atmospheric  Sciences  Laboratory  to  numerically  calculate  broadband  transmittances  (Davis  et  al,  1990). 
This  model  is  located  in  the  Electro-Optical  Atmospheric  Effects  Library  (EOSAEL).  The  BITS  model 
includes  spectral  effects  of  the  atmosphere,  detectors,  filters,  optical  surface,  targets,  and  obscurants  on 
broadband  transmittances.  The  BITS  model  allows  the  user  to  input  the  spectral  response  of  the  detector 
and  filters  into  the  model  as  spectral  response-wavelength  pairs.  However,  most  project  managers  of 
target  acquisition  systems,  have  their  own  in-house  system  performance  model.  SLAD  has  been 
requested  by  the  Stinger  project  office  to  provide  spectral  attenuation  for  use  in  just  such  a  model.  An 


1 


option  to  access  a  file  containing  the  variation  in  extinction  to  compute  the  spectral  attenuation  over  a 
band-pass  specified  by  the  user  has  been  added  to  the  model. 

Davis,  Berrick  and  Gillespie  in  1990,  performed  a  comparative  study  between  the  Beer’s  law  calculation 
and  band-integrated  calculations  of  WP  smoke  for  ASL  SMART  transmissometer  using  the  BITS  model. 
To  simplify  the  analysis,  the  target  spectral  signature  and  the  system  optics  were  assumed  to  be 
wavelength  independent  and  have  been  set  to  unity.  They  found  that  large  differences  between  predicted 
transmittances  using  an  averaged  extinction  coefficient  when  compared  to  spectral  extinction  can  occur. 
These  differences  for  the  conditions  modeled  can  be  important  below  transmittance  of  .1,  the  range  in 
which  threshold  of  detection  becomes  critical  for  most  sensors. 

Sutherland,  Yee,  Fernandez  and  Millard  also  made  a  comparison  study  in  1996  for  various  types  of  fog. 
They  modeled  the  mass  extinction  coefficient  as  a  constant  mean  component  and  a  wavelength  dependent 
component.  The  received  signal  can  be  considered  as  being  composed  of  a  wavelength  independent  part 
multiplied  by  a  correction  factor.  They  found  that  the  correction  factor  is  nearly  one  for  advective  fog 
where  the  mass  extinction  coefficient  is  nearly  independent  of  wavelength.  For  other  types  of  fog  like 
artificial  fog  and  radiative,  there  is  increasing  departure  of  the  correction  factor  from  one  with  increasing 
CL.  Though,  the  correction  factor  can  be  ignored  except  for  very  high  CL  values. 

It  is  convenient  to  also  use  a  band-averaged  emissivity  to  describe  the  background  for  infrared  scenarios. 
The  emissivity  is  defined  as  the  ratio  of  radiant  emittance  of  the  surface  to  the  radiant  emittance  of  a 
blackbody  at  the  same  temperature.  Most  IR  scene  generation  models  use  band-averaged  emissivities. 
For  some  backgrounds,  the  emissivity  is  nearly  constant.  However,  other  backgrounds  exhibit  some 
variation  in  the  emissivity  with  wavelength.  The  addition  of  an  obscurant  that  exhibits  variation  in 
extinction  over  the  wavelength  band  causes  the  apparent  emissivity  to  vary  further.  This  reports  shows 
how  the  apparent  emissivities  for  several  backgrounds  vary  in  the  presence  of  White  Phosphorus  for 
different  CLs. 

With  the  recent  emergence  of  the  eyesafe  laser,  the  Combined  Arms  Strategic  Task  Force  Evaluation 
Model  (CASTFOREM)  needed  the  capability  to  model  obscuration  effects  on  these  sensors. 
Phosphorus-based  smokes  are  found  in  most  country’s  inventory.  CASTFOREM  models  these  smokes 
using  the  COMBIC  model.  However,  the  default  tables  in  COMBIC  do  not  contain  extinction  at  1.54 
microns  for  WP.  The  effectiveness  of  these  smokes  is  dependent  on  the  ambient  relative  humidity. 
COMBIC  uses  a  fourth-order  extinction  equation  to  compute  the  extinction.  The  coefficients  of  this 
equation  are  dependent  upon  the  wavelength  and  the  type  of  smoke.  The  Aerosol-Hygroscopic  code  was 
used  to  help  determine  these  coefficients.  These  coefficients  are  also  determined  for  the  ultraviolet  (UV) 
wavelengths  of  .3  microns.  Several  systems  such  as  Stinger  use  a  UV  sensor  in  addition  to  another 
wavelength  to  help  discriminate  targets  from  false  targets.  The  Aerosol-Hygroscopic  code  is  used  partly 
because  a  dearth  of  actual  measured  extinction  data  for  WP  at  1.54  microns  and  UV  wavelengths  exists. 

2.  Models 

2.1COMBIC 

The  COMBIC  computer  simulation  predicts  spatial  and  temporal  variation  in  transmission  produced  by 
various  munitions  and  vehicles.  COMBIC  models  the  effects  of  reduction  in  electromagnetic  energy 
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(visible  through  infrared  (IR)  wavelengths)  by  combining  the  munition  characteristics  with  meteorological 
information  of  an  idealized  real  world.  It  produces  transmission  histories  at  any  of  seven  wavelength 
bands  for  a  potentially  unlimited  number  of  sources  and  lines  of  sight  (LOS.  The  extinctions  for  the 
seven  wavelengths  for  twenty  obscurants  are  included  in  the  model.  COMBIC  also  has  the  capability  of 
modeling  the  variation  of  extinction  with  wavelength  for  hygroscopic  smokes  like  WP  (Ayres  and 
DeSutter,  1993).  Path-integrated  concentration  is  determined  for  each  observer  (seeker) -target  pair,  and 
transmittance  are  computed  at  each  of  seven  wavelength  bands  for  (in  principle)  any  scenario  which  is 
defined  by  multiple  sources  and  active  LOS. 

2.2  Aerosol-Hygroscopic  Code 

The  mass  extinction  coefficient  is  a  wavelength-dependent  optical  property  of  the  obscurant  material.  It 
can  also  depend  on  the  particle  size  distribution,  particle  composition,  refractive  indices,  shape  and 
orientation.  Most  established  smokes  in  the  US  inventory  and  modeled  by  COMBIC’ s  default  tables  are 
considered  to  be  spherical.  The  mass  extinction  coefficients  for  many  smokes  in  these  default  tables  are 
heavily  weighted  towards  measurements  rather  than  theory.  COMBIC  uses  the  extinction  per  unit 
obscurant  concentration  integrated  over  the  entire  size  distribution  of  airborne  particles.  The  model  also 
uses  a  band-averaged  mass  extinction  coefficient  for  wavelength  bands  .4  -  .7  microns,  .7  -  1.2  microns, 
3-  5  microns,  and  8-12  microns.  The  extinction  coefficient  in  COMBIC  accounts  for  scattering  of 
radiation  out  of  the  path  of  propagation  and  absorption  of  radiation  along  the  path  of  propagation. 

White  Phosphorus  and  Red  Phosphorus  burn  to  produce  a  hygroscopic  smoke  containing  phosphoric 
acids.  The  extinction  for  these  smokes  is  primarily  due  to  scattering  in  the  visible  and  absorption  in  the 
infrared  (IR).  These  smokes  are  composed  of  spherical  liquid  particles  that  grow  with  relative  humidity 
to  an  equilibrium  size  by  absorbing  ambient  moisture  that  depends  on  the  ambient  relative  humidity.  The 
mass  extinction  varies  significantly  with  relative  humidity.  Theory  is  needed  to  supplement  measurements 
to  compute  the  extinction  variation  for  the  various  wavelengths  over  all  relative  humidities.  Extinction  of 
airborne  aerosol  (m**2/g)  depends  on  four  factors:  (1)  the  index  of  refraction  of  the  obscurant;  (2)  the 
distribution  of  particle  sizes;  (3)  shape  and  orientation  of  particles;  and  for  hygroscopic  smokes;  (4)  the 
effect  of  dilution  by  water  absorbed  from  the  air  on  mass,  size  distribution  and  effective  refractive  index 
(Hoock  and  Sutherland,  1993).  White  Phosphorus  smoke  can  be  modeled  as  spheres  allowing  the  use  of 
the  Mie  theory. 

The  Mie  theory  provides  exact  computation  of  absorption,  scattering  and  extinction  coefficients  for  an 
individual,  homogeneous  sphere  based  upon  the  particle  radius,  mass  density  and  refractive  index.  The 
problem  is  that  most  aerosols  have  particles  that  range  is  size.  Choosing  an  appropriate  size  distribution 
can  effect  results.  Furthermore,  hygroscopic  smoke  particle  size  distribution  and  indices  of  refraction 
change  concurrently  with  relative  humidity.  The  difficulty  is  to  compute  the  extinction  of  the  composite 
smoke  particle.  The  Aerosol-Hygroscopic  Code  produced  by  Klett  and  Sutherland,  1988,  is  based  upon 
the  Mie  theory  and  utilizes  a  lognormal  particle  distribution.  The  geometric  mean  radius  and  the 
geometric  mean  standard  deviation  o  characterize  this  distribution.  The  model  uses  the  refractive  indices 
for  water  and  WP,  combined  with  lognormal  particle  size  distribution  dependent  upon  relative  humidity 
to  compute  the  mass  extinction  coefficients  vs.  wavelength  for  any  desired  relative  humidity.  Though  the 
refractive  indices  for  water  are  well  known,  the  indices  for  the  composite  smoke  particle  must  be  modeled 
with  mixing  rules.  The  Aerosol-Hygroscopic  model  uses  the  rule  of  volumetric  additivity  of  dielectric 
constants  (Newton’s  rule)  as  the  mixing  rule. 
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Figure  1  shows  the  mass  extinction  coefficient  for  various  relative  humidities  using  Kletts  and 
Sutherland’s  (1988)  Aerosol-Hygroscopic  Code.  The  mass  extinction  coefficient  in  the  visible  region 
actually  decreases  at  high  relative  humidities.  This  is  due  to  the  particle  size  distribution  shift  to  larger 
radii  with  the  absorption  of  moisture  and  the  resultant  decrease  in  refractive  index.  Water  vapor  is  the 
strongest  absorber  for  clear  air  in  the  8-12  microns.  Klett  and  Sutherland  found  that  vapor  depletion  in 
the  aerosol  could  be  ignored  except  for  high  CL.  Note,  that  the  refractive  indices  for  WP  peak  in  the  8  - 
12  microns  wavelength  band.  The  Aerosol-Hygroscopic  Code  is  used  in  this  effort  to  compute  the 
extinction  at  .3  and  1.54  microns  and  to  compute  the  spectral  extinction  coefficient. 


Aerosol  Code  White  Phosphorus  Mass  Extinction 
Coefficient  Vs  Wavelength 
for  Several  Relative  Humidities 


Wavelength  (um) 


Figure  1  The  variation  of  the  White  Phosphorus  mass  extinction  coefficient  vs  wavelen 
shown  for  10%,  30%,  50%,  70%  and  90  relative  humidities 


3.  Near  IR 
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Laser  rangefinders  measure  the  time-of-flight  of  a  short  pulse  of  laser  light  to  and  from  a  target.  This 
time  of  flight  is  then  converted  to  a  range,  which  is  displayed  in  the  rangefinder’s  sighting  optics.  Most 
laser  rangefinders  are  not  eyesafe.  This  limits  their  use  in  training  and  provides  safety  concerns  in  the 
field.  Many  of  these  lasers  emit  a  wavelength  of  1 .064  microns.  While  invisible  to  the  human  eye,  this 
wavelength  is  not  only  passed  through  the  eye  to  the  retina,  but  is  also  focused  by  the  eye’s  lens  onto  the 
retina.  At  1 .064,  microns  the  maximum  permissible  exposure  for  single  pulse  lasers  is  limited  to  a  few 
microjoules  of  energy.  Hence  at  the  nominal  15mJ  operating  output  levels  of  some  lasers,  the  potential 
for  eye  damage  is  quite  high  (Galoff  and  Sliney,  1990).  Neutral  density  filters  were  developed  that 
reduced  the  eye  hazard  of  these  lasers  but  the  operational  usage  of  the  1. 06-micron  lasers  was  also 
reduced. 


Beyond  1.4  microns,  the  eye  no  longer  focuses  laser  energy  on  the  retina  and  higher  energy  levels  can  be 
tolerated.  Several  types  of  lasers  were  studied  that  operated  at  different  wavelengths,  but  the  Army 
eventually  settled  on  a  1 .54  micron  laser  that  was  eyesafe  at  the  aperture,  even  when  viewed  with 
magnifying  optics.  Full  scale  production  of  the  Mini  Eyesafe  Laser  Infrared  Observation  Set  (MELIOS) 
has  started.  An  unintentional  benefit  of  switching  from  the  1 .06  micron  laser  to  the  1 .54  micron  laser  is 
that  the  extinction  is  significantly  reduced.  A  quick  inspection  of  figure  1  shows  that  the  extinction  curve 


is  quite  steep  in  the  near-IR.  Assuming  that  the  WP  mass  extinction  coefficient  for  the  1.54  wavelength 
and  the  1.06  wavelength  is  the  same  would  introduce  errors  up  to  200%  in  computing  optical  depth.  In 
order  to  compute  the  1.54  micron  mass  extinction  coefficient,  the  Aerosol-Hygroscopic  Code  was  run 
with  varying  geometric  mean  radius  and  standard  deviation  o  for  1.06  microns  until  the  best  fit  with 
COMBIC  produced  mass  extinction  coefficients  was  obtained. 


Comparison  of  COMBIC  vs  Aerosol  Code's  Mass 
Extinction  Coefficient  Vs  Relative  Humidity  for  1.54 
and  1.06  microns 


- COMBIC  1.06  um 

Aerosol  1 .06  um 

- COMBIC  1.54 

Aerosol  1 .54  um 


Figure  3  White  Phosphorus  Mass  extinction  coefficient  vs.  relative  humidity 
and  1.54  microns  computed  by  COMBIC  and  the  Aerosol-Hygroscopic  Cod< 


COMBIC  computes  the  mass  extinction  coefficient  through  the  following  empirical  equation: 
a  (X )  =  ax  *  RH  +  a2  *  RH 2  +  a,  *  RH 3  +  a4  *  RH 4 

where  a(A.)  is  the  mass  extinction  coefficient  for  wavelength  or  wavelength  band  and  RH  is  the  relative 
humidity.  Curve  fitting  the  1 .54  micron  data  produced  by  the  Aerosol-Hygroscopic  Code  yields  ax  = 
5.2782E-02,  a^=  -2.0106E-03,  a3  =  2.9326E-05,  and  a4  =  -1.3817E-07.  The  correlation  coefficient  is 

.962  proving  that  the  derived  curve  for  COMBIC  strongly  matches  the  data  produced  by  the  Aerosol- 
Hygroscopic  model.  Figure  2  shows  the  mass  extinction  coefficient  vs.  relative  humidity  computed  by 
COMBIC’ s  empirical  extinction  equation  for  1.06  and  1.54  microns  and  by  the  Aerosol- Hygroscopic 
code  for  1 .06  microns  and  1 .54  um.  Geometric  mean  radius  and  sigma  used  by  the  Aerosol-Hygroscopic 
code  is  r  =.  215  microns  and  o  =1.2  microns.  Note  that  the  agreement  between  COMBIC  and  the 
Aerosol-Hygroscopic  code  at  1.06  microns  is  quite  good  with  a  root-mean-square  (rms)  deviation  of 
2.85%.  Thus,  there  is  a  large  degree  of  consistency  between  COMBIC  and  the  Aerosol-Hygroscopic 
Code. 

4.  UV  Extinction 


Currently,  COMBIC  contains  in  its  default  tables,  extinction  data  from  visible  to  far  IR.  However,  some 
sensors  operate  in  the  ultraviolet  (UV).  Also,  UV  emissions  are  considered  a  missile  observable.  UV 
extinction  for  some  non-hygroscopic  smokes  have  been  collected  elsewhere  (Johnston  and  Rouse  1997). 
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The  coefficients  for  the  extinction  equation  used  by  COMBIC  is  needed  for  hygroscopic  smokes.  The 
same  methodology  used  in  computing  the  coefficients  for  COMBIC’ s  empirical  extinction  equation  at 
1.54  microns  is  used  here.  However,  the  Aerosol-Hygroscopic  model  is  run  to  compute  the  mean 
geometric  radius  and  standard  deviation  that  gives  a  best  match  with  COMBIC  at  visual  wavelengths. 
These  values  are  then  used  in  the  Aerosol-Hygroscopic  model  to  compute  the  extinction  at  .3  microns. 
Figure  3  shows  the  mass  extinction  coefficient  vs.  relative  humidity  for  .4  -  .7  microns  and  .3  microns 
produced  by  the  Aerosol- Hygroscopic  model  and  by  COMBIC’ s  extinction  equation  for  WP.  The 
geometric  radius  is  .215  microns  and  geometric  standard  deviation  o  is  1.5  microns.  The  rms  percent 
difference  between  the  two  models  for  the  visual  waveband  is  6.8.  The  coefficients  for  the  extinction 
equation  used  by  COMBIC  at  UV  wavelengths  become  ax  =  5.2782E-02,  a2=  -2.0106E-03,  a3  = 

2.9326E-05,  and  a4  =  -1.3817E-07.  A  zeroth-order  term,  a0=  3.3420  had  to  be  added  in  order  to 

obtain  the  best  fit.  The  correlation  coefficient  is  .997  proving  that  the  derived  curve  for  COMBIC 
strongly  matches  the  data  produced  by  the  Aerosol-Hygroscopic  model. 


Note  that  the  agreement  between  COMBIC’ s  extinction  equation  and  the  Aerosol-Hygroscopic  model  for 
visual  wavelengths  is  fairly  good  for  humidities  above  30%.  There  is  increasing  discrepancy  below  30% 
relative  humidity.  One  possible  source  for  this  discrepancy  could  be  that  the  indices  of  refraction  for  dry 
WP  particulate  were  extrapolated  from  “wet”  indices.  However,  the  extinction  at  visual  wavelength  for 
WP  is  believed  to  be  insensitive  to  the  indices.  Another  possible  source  of  discrepancy  is  that  the 
extinction  at  visual  wavelengths  is  very  sensitive  to  the  particle  size  distribution.  Figure  1  shows  the 
extinction  exhibits  a  marked  peak  at  visual  wavelengths.  Changing  the  geometric  mean  radius  or  sigma 
even  slightly  can  have  significant  effects  on  the  extinction.  The  values  computed  by  here  are  believed  to 
be  well  within  the  noise  of  real  world  values. 


Comparison  of  WP  Mass  Extinction  Coefficient  for 
COMBIC  and  the  Aerosol  Code  for 
Visual  and  UV  Wavelengths 


Figure  4  Comparison  of  WP  mass  extinction  coefficient  for  COMBIC  and  the  Aerosol 
Code  for  visual  and  UV  wavelengths. 


5.  Spectral  Emissivities  of  Some  Natural  Soils  and  Vegetation 

The  variation  of  the  mass  extinction  coefficient  can  effect  the  natural  emissivity.  Figures  4-7  shows  the 
emissivity  of  red  clay,  fine  sand,  coarse  sand  and  a  tree  leaf  for  the  8-14  um  region  (Sutherland,  1986)  for 
clear  air  (top  curve)  and  for  increasing  WP  CL  values.  These  figures  show  that  the  spectral  attenuation 
of  WP  in  this  wavelength  region  adds  a  spectral  dependency  to  the  emissivity  that  may  not  be  present  in 
clear  air.  The  reason  for  this  variation  is  that  the  refractive  indices  of  phosphoric  acid  droplets  vary  the 
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most  with  relative  humidity  in  the  8-12  micron  wavelength  band  (Hoock  and  Sutherland,  1993).  The 
emissivity  for  tree  leaf  was  nearly  constant  over  the  wavelength  band  in  clear  air.  For  increasing  CL 
values,  the  figures  show  that  there  is  an  increasing  wavelength  dependence  of  the  apparent  emissivity  of  a 
tree  leaf  for  this  wavelength  region.  This  is  also  true  for  clay  and  fine  sand.  The  effects  of  smoke  on 
coarse  sand  is  somewhat  different.  At  increasingly  higher  CL  values  the  smoke  degraded  some  of  the 
natural  variation  in  emissivity. 


TRANSMITTED  EMISSIVITY  OF  CLAY  TRANSMITTED  EMISSIVITY  OF  COARSE  SAND 

THROUGH  WP  FOR  DIFFERENT  CLs  THROUGH  WP  FOR  DIFFERENT  CLs 


- EMISSIVITY 

CL  =  .5 
■--CL  =1.0 
CL  =  2.0 
. CL  =  6.0 
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- CL  =  .5 

-  -  CL  =  1.0 
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Figure  4  Emissivity  for  red  clay  for  8  - 
14  microns 


Figure  5  Emissivity  for  coarse  sand  for  8  - 14 
microns 


TRANSMITTED  EMISSIVITY  OF  FINE  SAND 
THROUGH  WP  FOR  DIFFERENT  CLs 


TRANSMITTED  EMISSIVITY  OF  TREE  LEAF 
THROUGH  WP  FOR  DIFFERENT  CLs 
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Figure  6  Emissivity  for  fine  sand  for  8- 

Figure  7  Emissivity  for  tree  leaf  for  8  - 

14  um 

14  microns 

6.  Conclusion  and  Future  Work 


Analysis  of  the  WP  mass  extinction  coefficient  computed  by  the  Aerosol-FIygroscopic  code  shows  that  it 
compares  very  favorably  with  the  extinction  coefficient  computed  by  COMBIC  at  .4  -  .7  microns  and 
1.54  microns.  Therefore,  the  code  can  be  used  with  confidence  to  compute  the  mass  extinction 
coefficient  variation  with  relative  humidity  at  .3  microns  and  1.54  microns.  The  data  is  curve  fitted  for 
each  wavelength  using  a  fourth  order  polynomial  for  eventual  inclusion  in  COMBIC  extinction  module 
for  use  by  CASTFOREM.  The  correlation  coefficient  is  quite  high  (>  .95)  between  the  Aerosol- 
Hygroscopic  code  data  and  the  fourth  order  equation  used  by  COMBIC. 
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The  effect  of  smoke  on  natural  emissivities  is  complex.  The  spectral  variation  of  the  backgrounds 
examined  in  this  report  increased  with  increasing  CL  except  for  coarse  sand.  The  effect  of  smoke  on 
coarse  sand  is  to  “wash  out”  some  of  the  natural  variation  in  spectral  emissivity.  Analysis  shows  that  the 
range  of  the  transmitted  emissivity  for  coarse  sand  at  8  -  14  microns  through  WP  smoke  at  moderate  CL 
values  of  6  g/m2  is  .29.  The  range  in  emissivity  for  coarse  sand  without  smoke  is  .42. 

Future  work  will  include: 

•  Acquiring  data  for  validation  of  coefficients  of  extinction  equation  for  .3  and  1.54  microns 

•  Add  extinction  for  .3  microns  and  1.54  microns  to  the  default  tables  (CASTFOREM) 

•  Using  COMBIC  and  the  hygroscopic  code  to  compute  the  spectral  attenuation  over  the 
bandpass  for  STINGER. 

•  Inclusion  of  sensor  effects  and  aerosol  emissivity  (Nealon  and  Sutherland,  1999) 
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1  Introduction 


Silent  Sentry™  2  (SS2)  is  Lockheed  Martin's  new  all-weather,  passive  surveillance  technology.  The  SS2  system 
is  a  receive  system  that  exploits  transmissions  from  multiple  commercial  FM  radio  stations  to  passively  detect 
and  track  airborne  targets  in  real-time.  On  10  May  1999,  Silent  Sentry  received  Aviation  Week  &  Space 
Technology  magazine’s  Technology  Innovation  Award,  which  recognizes  innovative  product  and  service 
technologies  in  the  global  aerospace  business. 

Last  year,  Lockheed  Martin  Mission  Systems  publicly  announced  the  Silent  Sentry  system.  Since  then, 
the  development  team  has  migrated  the  technology  to  a  prototype,  mobile  platform  and  validated  the 
system’s  surveillance  accuracy  during  a  recent  military  exercise  held  to  evaluate  current  and  emerging 
technologies.  The  March  1999  All  Services  Combat  Identification  and  Evaluation  Team  (ASCIET)  Joint 
Services  Exercise  at  Ft.  Stewart,  Georgia  provided  the  team  an  opportunity  for  real-time  testing  of  Silent 
Sentry  against  a  variety  of  aircraft,  including  fighter,  bomber  and  radar  surveillance  aircraft  and 
helicopters. 

The  heart  of  Silent  Sentry  is  its  innovative  Passive  Coherent  Location  (PCL)  technology  developed  by 
Lockheed  Martin  Mission  Systems,  which  uses  everyday  broadcast  signals,  such  as  those  for  television 
and  radio,  to  illuminate,  detect  and  track  objects.  A  passive  detection  system  for  U.S.  government  civil 
agency  and  military  purposes.  Silent  Sentry  transmits  no  radio  frequency  (RF)  energy  as  conventional 
radar  does  and  has  no  RF  "signature"  to  alert  enemy  threats.  Instead,  it  can  use  the  energy  that  already 
exists  in  airspace  for  detection  purposes,  and  does  not  adversely  affect  or  harm  the  environment. 

By  using  broadcast  transmitters  and  signals  available  throughout  the  world.  Silent  Sentry: 

•  assists  in  casting  a  "wider  net"  when  used  in  conjunction  with  existing  surveillance  systems, 

•  provides  new  levels  of  early  detection,  to  reveal  tangible  proof  of  activity,  and 

•  enables  rapid,  defensive  reaction  to  threats. 

The  system  can  be  deployed  to  fill  gaps  in  existing  radar  coverage  and  enhance  global  awareness  and 
command-control  decision-making. 

Silent  Sentry  is  a  multi-static  illuminator  surveillance  system  (i.e.,  receiver  and  transmitters  are  not  co¬ 
located)  which  determines  precise  three-dimensional  target  trajectories,  and  unlike  "scanning"  radars. 
Silent  Sentry  provides  continuous  coverage  of  the  airspace.  The  Silent  Sentry  configurations  include 
versions  which  can  be  mounted  in  buildings  and  fixed  structures,  or  in  deployed  configurations,  such  as 
trucks,  or  shelters,  for  rapid  relocation. 

Recent  advances  in  commercial  technology,  such  as  high-speed  processors  and  high  dynamic-range 
receivers,  help  make  Silent  Sentry  a  low-cost  approach  to  effective  and  reliable  real-time  surveillance 
against  a  wide  range  of  potential  threats.  A  typically  configured  system  includes  Silicon  Graphics,  Inc.® 
processors,  the  Autometric  Edge  Product  Family™  visualization  and  analysis  software,  and  receivers  built 
by  Lockheed  Martin  from  commercial  products.1 


1  Silent  Sentry  is  a  trademark  of  the  Lockheed  Martin  Corporation. 
Silicon  Graphics  is  a  registered  trademark  of  Silicon  Graphics,  Inc. 
Autometric  Edge  Product  Family  is  a  trademark  of  Autometric,  Inc. 
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2  What  is  Silent  Sentry™?  (An  Overview) 


2.1  SS2  Basic  Concept  and  Features 

SS2's  continuous  wave  (CW)  multistatic  technology  provides  an  all-weather,  passive  surveillance  capability 
through  the  exploitation  of  radiant  energy  from  commercial  FM  radio  stations.  The  transmitted  signals  from 
these  illuminators  are  scattered  from  airborne  targets  and  received  by  the  SS2  target  antenna  (a  horizontal  linear 
phased  array  antenna  in  the  current  implementation).  Separate,  reference  antennas  also  receive  the  direct  path 
signals  from  the  FM  transmitters.  High  dynamic-range  receivers  are  used  to  accommodate  the  dynamic  range 
requirements  for  receiving  direct  and  scattered  signals  simultaneously. 


Basic  Concept  of  Silent  Sentry  Operation 

Continuous  coverage  of  90  degrees  azimuth  is  achieved  through  the  use  of  innovative  digital  signal  processing 
algorithms.  Delay  (time  difference  of  arrival)  and  Doppler  (frequency  difference  of  arrival)  measurements  for 
each  detected  target  are  extracted.  The  measurement  data  are  associated  by  target  and  a  tracking  filter  estimates 
the  state  vector  (position,  velocity,  and  acceleration)  for  each  target.  This  state  data  can  then  be  presented  to  a 
tactical  display  or  communicated  to  other  systems  via  standard  data-links. 

In  the  current  version  of  SS2,  coarse  2-D  tracking  solutions  are  possible  when  the  target  is  detected  using  a 
single  illuminator.  Good  2-D  solutions  are  feasible  whenever  the  target  is  detected  on  two  or  more  geometrically 
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diverse  FM  illuminators.  Tracking  solutions  in  3-D  are  feasible  when  the  target  is  detected  on  three 
geometrically  diverse  FM  illuminators. 

The  system  can  provide  short  latencies  since  it  is  a  staring,  not  a  scanning,  system.  (Recall  that  traditional  radar 
uses  pulsed  signals,  in  part  due  to  their  monostatic  design.)  The  FM  illumination  continuously  saturates  the 
coverage  region  and  SS2,  with  its  staring  beams  spanning  the  coverage  region  and  high  update  rate,  enabling 
early  target  detection.  The  use  of  commercial  broadcast  transmitters  provides  excellent  low  altitude  illumination 
of  targets,  which,  when  combined  with  favorable  receiver  siting,  provides  low  altitude  surveillance. 

2.2  System  Description 


Silent  Sentry  System  Description 

Silent  Sentry  is  a  single  receive  system  composed  primarily  of  the  following  components  the  majority  of  which 

are  commercial  off-the-shelf  (COTS): 

•  Target  array  -  a  linear  phased  array  for  detecting  the  scattered  energy  from  targets  in  the  region  of 
interest 

•  Reference  antennas  -  single  elements,  identical  to  those  in  the  target  array,  used  for  reception  of  the 
direct  path  signals  from  the  FM  illuminators 

•  High  Dynamic  Range  Receivers  —  accommodate  the  dynamic  range  requirements  for  receiving 
direct  and  scattered  signals  simultaneously 
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A/D  Converters  —  the  system  possesses  the  capability  to  record  data  at  this  level,  which  is 
particularly  useful  for  post-mission  analysis 

Processor  -  Silicon  Graphics,  Inc.  (SGI)  general  purpose  processor 


•  Displays  -  SGI  Octane  workstation  and  visualization  products  from  the  Autometric  Edge  Product 
Family™ 

•  High  Speed  Tape  System  -  a  SCSI  attached  striping  tape  controller  with  5  tape  drives 

Mission  planning  and  system  performance  predications  are  critical  for  any  surveillance  system  and  imperative 
for  line-of-sight  systems.  Silent  Sentry  includes  a  suite  of  mission  planning  and  system  tools  that  are  collectively 
called  the  Sensor  Performance  and  Analysis  Tools  (SPAT).  Among  these  tools  are  signal  simulators,  a  trajectory 
simulator,  beam  formulator.  Signal  to  Noise  Ratio  (SNR)  calculator,  and  an  illuminator  database.  These  tools  in 
combination  with  several  other  standard  radar  modeling  tools  were  utilized  in  planning  and  preparation  for 
ASCIET  mission  at  Ft.  Stewart  in  March  1999.  The  essential  functions  of  SPAT  are: 

•  Illuminator  Selection  and  Receiver  Siting  -  analyzes  illuminator  coverage  for  various  combinations 
of  FM  radio  stations  in  combination  with  the  receiver  location. 

•  Performance  Prediction  -  for  a  given  site  and  combination  of  illuminators  and  trajectory,  determines 
the  probability  of  detection,  the  accuracy  and  SNR  values. 

2.3  SS2  Configurations 

Fockheed  Martin  currently  has  two  configurations  of  SS2:  the  Fixed  Site  System  (FSS)  and  the  Rapid 
Deployment  System  (RDS). 


The  FSS  operates  in  Gaithersburg,  MD,  runs  real-time  using  a  full  configuration  of  processors,  and  processes  all 
data  real-time.  The  system  is  designed  for  flexibility,  with  many  aspects  of  the  system  configurable  according  to 
desired  data  processing  rate,  sampling  patterns,  performance  objectives,  and  available  hardware. 
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The  Fixed  Site  System:  Receivers  (left)  and  Wall-Mounted  Antenna  Array  (right). 

The  current  implementation  of  SS2  uses  only  the  horizontal  array  outlined  in  red. 
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The  Rapid  Deployment  System 


The  RDS  is  used  for  real-time  data  collection  and  real-time  data  processing.  The  RDS  is  currently 
deployed  in  a  self-sufficient  trailer  including  power  and  environmental  controls.  It  is  contained  in  a  van, 
with  the  phased  array  antenna  mounted  on  the  side,  and  the  reference  antennas  on  the  top.  The  mggedized 
receivers,  processors  and  control  workstation  are  contained  in  half  the  van.  The  heating  system  and  generator 
are  housed  in  the  other  half.  The  van  is  a  Faraday  cage  to  prevent  emissions  from  the  processors  from 
interfering  with  the  antenna  reception.  This  configuration  was  used  at  the  recent  testing  event  reported  above. 
The  van  is  larger  than  required  for  deployed  operations,  but  was  an  available  asset  in  the  Lockheed  Martin 
inventory. 


3  Capabilities  of  Silent  Sentry™ 


•  Silent  Sentry  has  some  inherent  features  and  unique  capabilities  that  warrant  examination. 

•  Surveillance  for  Challenging  Targets 

•  The  ASCIET  Joint  Services  Exercise  at  Ft.  Stewart,  Georgia,  in  March  1999  gave  Lockheed  Martin 
an  opportunity  for  real-time  testing  of  its  Silent  Sentry  system  against  a  variety  of  aircraft,  including 
fighter,  bomber  and  radar  surveillance  aircraft  and  helicopters.  In  past  technology  experiments, 
Lockheed  Martin  has  demonstrated  nonreal-time  and  real-time  capabilities  against  a  variety  of  other 
targets,  including  helicopters,  rockets,  ballistic  missiles,  and  re-entry  vehicles. 

•  Excellent  Altitude  Coverage 

•  Since  TV  and  FM  broadcast  stations  focus  energy  toward  the  Earth's  surface,  they  illuminate  low 
flying  targets.  Multi-illumination  not  only  provides  illumination  to  areas  where  mountains  and 
valleys  may  block  one  illumination  source,  but  the  geometric  diversity  provides  additional 
information  from  differing  viewing  aspects  of  the  targets. 

•  Inherent  Survivability 

•  Active  radars  quickly  become  combat  targets  due  to  their  energy  emissions.  Silent  Sentry  is  a  truly 
passive  system,  which  emits  no  signal,  so  it  is  well  suited  to  passive  operation.  Silent  Sentry  is  also 
an  “environmentally  friendly”  sensor  since  it  reuses  commercial  illumination  energy  (instead  of 
disrupting  the  broadcasts  with  its  own  strong  signals). 

•  Effective  All  Weather  Operation 

•  Broadcast  Signals  in  the  UHF,  VHF,  and  FM  bandwidths  are  virtually  immune  to  weather-induced 
degradation  and  operate  equally  well  day  and  night. 

•  Military  Operations 

•  Since  Silent  Sentry  emits  no  signals,  it  can  be  placed  forward  on  the  battlefield  without  being 
detected,  providing  earlier  warning  of  potential  threats  and  expanding  the  battlespace  understanding. 

•  Low  System  Cost 

•  Silent  Sentry  is  a  phased  array  system  with  no  rotary  mechanical  components;  in  addition,  it  has  no 
transmission  components.  These  attributes  greatly  reduce  power  requirements,  mechanical  upkeep. 
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and  cost.  In  addition,  the  system  is  primarily  composed  of  COTS  products  and  can  be  fielded  in 
unmanned  configurations . 

•  SS2  Design  Goals 

•  The  advertised  system  performance  figures  are  dependent  on  several  factors;  the  most  important  of 
which  are  the  geometric  diversity  of  the  illuminators,  the  illuminator  transmission  power,  and  the 
Radar  Cross  Section  (RCS)  of  the  target. 


Performance  of  a  mid-range  system  configuration 


System  Parameter 

Value 

*  Detection  Range 

220  km 

Range  Depth  Coverage 

150  km 

Azimuth  Coverage 

60°  to  360° 

Elevation  Coverage 

50° 

Target  Tracking  Update  Rate 

8  per  second 

Target  Capacity 

200+ 

Power  requirements 

10  kW 

Footprint  (excluding  antenna) 

27  square  feet 

*  Value  based  upon  an  RCS=10  m2  @  100  MHz,  Pd  >  0.95,  FAR  <  10T 

•  Mission  Planning  Tools 

•  There  are  a  significant  number  of  performance  prediction  and  planning  tools  available  as  part  of 
Silent  Sentry.  The  mission  planning  and  illuminator  selection  tools  allow  for  system  deployment  (or 
simulation)  anywhere  in  the  world  based  on  the  FCC  and  ITU  transmitter  databases. 


4  Conclusion/Forward  Plan 


The  system  is  intended  as  a  passive  detection  and  tracking  system  for  U.S.  government  civil  agency  and 
military  purposes;  it  can  be  deployed  to  address  gaps  in  radar  coverage  to  provide  “early  warning” 
detection,  and  enhance  command  and  control  decision-making.  The  Silent  Sentry™  architecture  is 
designed  to  be  expandable  and  scalable. 

The  characteristics  are: 

•  Sensitivity  to  allow  range  detection  of  a  wide  variety  of  targets 

•  Exploitation  of  continuous  wave  (CW)  signals  allowing  for  high  update  rates 

•  Complete  and  continuous  airspace  coverage  (within  system  parameters) 

•  Local  operations  and  remote,  controlled  system  access 

Silent  Sentry™  provides: 

•  Real-time  three  dimensional  tracking  and  visualization  of  airborne  targets 

•  Exploits  multiple  sources  of  illumination  (i.e.,  radio  and  TV  broadcast  signals  and  optional 
cooperative  transmitters) 

•  Comprehensive  data  recording  and  playback  capabilities 

•  Extensive  simulation  and  mission  planning  tools 

We  believe  that  Silent  Sentry  represents  the  threshold  of  an  exploding  new  technology.  The  technology 
has  the  potential  to  revolutionize  how  various  surveillance  operations  are  performed.  Recent  field 
exercises  have  proven  viability  of  the  technology  and  the  mission  planning  toolset.  We  look  forward  to 
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continued  research  and  development,  which  will  lead  to  addition  to  the  current  system  of  TV  signal 
exploitation,  as  well  as  refinement  of  various  processing  and  tracking  algorithms.  One  of  the  most 
exciting  features  of  Silent  Sentry  that  will  be  explored  further  is  the  inherent  signal  information  that  can 
be  used  for  target  identification  and  classification.  These  advancements  in  battlespace  awareness  will 
provide  increased  capability  and  robustness  to  the  warfighter. 


For  Additional  Information: 

More  information  regarding  Silent  Sentry  and  its  underlying  technology  can  be  obtained  at  this  Lockheed 
Martin  website: 

Error!  Bookmark  not  defined. 

Or  by  contacting: 

Tom  Kuba 

301-240-6668, 

tom.kuba@lmco.com. 
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